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Abstract 

This thesis presents formal specif icatton and verification techniques for both serial 
and parallel programs written in SIMULA-like object oriented languages. 

These techniques are based on the notion of states of individual objects which are 
defined uniformly in serial and parallel computations. They can specify and verify the 
behavior of data and procedural objects in multi-process environments, thus overcoming 
some of the difficulties in dealing with parallelism which characterized previous work on 
formal specifications for abstract data types. Among others, the specifications and 
verifications of a bounded buffer and air line reservation systems are given. 

Using a model of a simple post office, we illustrate our specification and 
verification techniques for systems, such as operating systems and multi-user data base 
systems, which are characterized by complex internal concurrent activities. It is 
demonstrated that the specifications of the overall functions of the system which we call 
task specifications can be dertved from specifications of the individual behavior and 
mutual interaction of the subsystems. 

A method of defining states of individual objects as mathematical functions is 
suggested. 
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1. Introduction 



1.1 Formal Specifications and Verifications 

A program specification is a description of the desired program behavior. It is 
necessary to specify what task the program is supposed to perform and what effects 
(side-effects) are caused by carrying out the intended task. 

Program specifications can be written in languages of varying degrees of 
formality. Although informal languages, such as natural languages, diagrams, and 
combinations of these, help people to convey intuitive ideas about program behavior, their 
inherent ambiguity is a drawback. In order to rule out the possibility of ambiguous 
interpretations, program specifications should be written in formal languages. When 
formal specifications might be difficult to understand, they may be accompanied by 
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informal descriptions of program behavior. 

Formal specifications play an important role in the construction of reliable 
software. They also provide designers and programmers with an exact communication 
medium for discussing the properties of program modules in various phases of software 
construction, such as initial design and coding. Furthermore, they can be used as 
documentation during the maintenance phase. A formal specification can be viewed as a 
contract which describes the agreements between the implementors of a program module 
and its users. The users of a module rely only on the properties derived from its formal 
specifications, while the implementors need only satisfy the requirements stated in the 
specifications. 

Program verification is the process of proving that a given program 
(implementation) meets its formal specifications. When a program module M is built on a 
collection of submodules, their formal specifications can be used in the verification of M. 
Actual programs (implementations) of the submodules need not be used. 



1.2 A Model of Parallel Computation 

This thesis is concerned with the technique* for formal specification and 
verification of both serial and parallel computations. 

In order to discuss specification and verification techniques, we must clearly define 
the computation model on which the execution of programs is baled. The computation 
model used in this thesis is the actor model of computa«on[Greif-Hewitt75. Hewitt-Baker771 
which can be roughly characterized as one obtained by generating the computation model 
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used in SIMULA-like object-oriented languages' to include parallelism. 

The fundamental objects in our model of computation are actors, which unify 
procedures and data structures. An actor is a potentially active object which becomes active 
when it receives a message. No actor treats other actors as objects to operate on; instead it 
sends messages (which are also actors) to other actors. Actors behave like data or data 
structures as well as functions or procedures. For example, a push-down-stack actor pops 
up and returns its top element when it receives a {pop:) message (if it is not empty), and 
when it receives a (push: •) message, it stores • as its new top element. A factorial actor 
returns 6 when it receives 3. 

The only activity possible in the model is message passing among actors. More 
than one transmission of messages may take place concurrently, which models parallel 
computations. Since processors and processes can be viewed as actors, multi-processor 
information systems and computer networks are modelled by actor systems. In particular, 
distributed systems* and communicating parallel processes can be easily modelled by actors 
or systems of actors[Yonezawa-Hewitt77, Hewitt-Baker771 

The concept of an event is fundamental in describing the model of computation 
precisely. An event is the receipt of a message by an actor. A computation is expressed as 
a partially ordered set of events, where the order relation represents the temporal "precedes" 
relation. Unordered events can take place concurrently. Thus the partial order of events 
naturally generalizes serial computations (which are totally ordered sets of events) to parallel 



1. Besides SIMULA-67[Dahl-et-al70], CLU[Schaffert-et-al75], ALPHARD[Wulf-et-al75] and 
SMALL-TALK[Learning-Research-Group76] are examples of such programming 
languages. 

2. Distributed systems are multi-processor information processing systems which do not rely 
on the central shared memory for communication. 
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computations. 

1.3 Local State Approach 

In this thesis, we propose an approach, called the ttial state Approach, for 
specifying the behavior oT actors (objects). In general, the behavior Of ah actor in response 
to a message depends upon the past history of messages teceived by the actor. By defining 
the state of an actor A as tquivaltrut dmssti mn the past massage histories of A, we can 
specify the behavior of A in response to a message M m terms of: 

(1) the state of A before A receives M, 

(2) a set of mutually concurrent events caused by the event where A receives M and 

(3) the state of A afjer A receives M. 

Since we assume, in the model of computation, that the order of message arrivals 
at the same actor is always total, the state of an actor is always wefrdefbted tot both serial 
and parallel computations. Consequently, the behavior of an actor in both serial and 
parallel computations can be specified in a uniform manner. 

We use the term "lacaf , to emphasise that our approach does not rely on the 
notions of the global clock, and the global state of a system.? The use of global states is 
often motivated by the use of non-deterministic serial computations a* the underlying 
semantic model for parallel computations. This leads to counter-intuitive serialization of 
unrelated concurrent events and a large number of possible cases in analyzing properties of 



1. The global clock is the unique time reference available within the entire system. The 
global state of the system at a given time t (by the global clock) to a vector of the states of 
system components determined at the same timet 
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the system. 

In our approach, the behavior of a system is specified in terms of the individual 
behavior of system components and their mutual interaction. Such behavior and 
interaction are described by the states of the system components determined at their local 
times. 



1.4 Contributions of the Thesis 

Based on the notion of local states, the work presented in this thesis has made 
several contributions to the area of program specification and verification. 

(1) Formal specifications of Abstract Data Types with Parallelism and Side-effects 

The importance of abstract data types[Liskov-Zilles74] in the construction of 
reliable software has been recognized and two approaches to the formal specification 
technique for abstract data types, i.e. algebraic axiomatic[Zilles74, Spitzen-Wegbreit75, 
Guttag75] and abstract model[Hoare72, Liskov-Berzins77] approaches, have been proposed. 
Yet none of the techniques of these approaches are able to deal with parallelism and 
side-effects. These techniques are only applicable to data objects without side-effects and 
they fail to specify the behavior of data objects which are used in parallel computations 
(multi-process environments). Our specification techniques have overcome these limitations. 
Formal specifications for an air line reservation system and bounded buffers will be given 
as illustrations of our techniques. 

(2) Conceptual Representations 

We have developed notational devices called conceptual representations to describe 
the states of individual actors (objects, and data structures) at various levels of abstraction. 
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The use of conceptual representations reinforces the notion of data and procedural objects 
as abstract entities whose internal structures are hidden. B| separating the states of an 
object from its identity, conceptual representations can express sharing among objects in an 
intuitive, yet rigorous manner. Thus our specification language wltfi its use of conceptual 
representations has flexible and powerful expressiveness. 

(3) Symbolic Evaluation of Programs written in Object-Oriented Languages 

Symbolic evaluation is a process which abstractly executes programs on abstract 
data. As the major tool for program verification, we have d eve lope d a method for 
symbolic evaluation of programs written in SIMULA-like object-oriented languages. Our 
formalism based on conceptual representations enables us to deal with the difficulties due 
to object sharing which often arise in verification of programs written in object-oriented 
languages. 

(4) Specifications of Systems with High Internal Concurrency and Task Specifications 

Little work has been done on specifying and verifying the behavior of a system 
characterized by complex concurrent activities of its subsystems. Operating systems and 
multi-user data base systems fall into this category. In order to illustrate our techniques for 
dealing with such systems, we give a model of a simple post office where a number of 
customers and mail-collectors are represented as internal concurrent activities. We show 
that the specifications of the over-all functions of such a system, which we call task 
specifications, are derived from the specifications of the individual behavior and mutual 
interaction of its subsystems. 
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1.5 Outline of the Thesis 

Chapter 2 introduces conceptual representations, which are extensively used in the 
work presented in this thesis. The precise syntax of conceptual representations and their 
uses in writing format specifications of abstract data, types without parallelism and 
side-eFfects are exemplified. Further, algebraic axiomatic and abstract model approaches to 
the specification of abstract data types are discussed in the light of our approach. (This 
chapter does not use the actor model of computation.) 

Chapter 3 gives a precise account of the actor computation model on which the 
discussion in the subsequent chapters is based. It atso describes certain characteristics of the 
behavior of actors which must be considered in the development of specification 
techniques. 

Chapter 4 presents our specification techniques for serial computation. The 
separation of the identities of objects from their states is explained and how this is 
incorporated into our formalism is illustrated before our specification language is 
introduced with examples of format specifications. Several other approaches to program 
specification are reviewed. 

Chapter 5 describes our method of symbolic evaluation and illustrates our 
verification techniques for serial computations based on the symbolic evaluation method. 
The application of symbolic evaluation to other domains is also discussed. 

Chapter 6 extends the specification language introduced in Chapter 4 to cover 
parallel computations and illustrates our techniques for writing formal specifications of 
abstract data types with parallelism and side-effects. The notion of local states of actors 
(objects) is discussed in detail in the beginning of the chapter. 

Chapter 7 presents our verification techniques for parallel computations. The 
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verifications of air line reservation systems and bounded buffers are illustrated. 

Chapter 8 contains an actor model of a simple post office, which is an intuitive 
example of a system with high internal concurrency. We show that the internal activities of 
the post of f ice meet its task specifications. 

Chapter 9 makes the concluding remarks and suggests future research. 
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2. Conceptual Representations 



Conceptual representations occupy the central role In the formal specification and 
verification techniques presented in this thesis. In this chapter, we will explain the basic 
idea of conceptual representations by illustrating how specifications of conventional data 
structures are written using conceptual representations. However, as will be seen in the later 
chapters, conceptual representations are used to describe states of actors of a wide variety. 
In the later part of this chapter, existing specification techniques for data structures (data 
types), such as algebraic axiomatic ones, and an abstract model approach, will be discussed 
in relation to the techniques based on conceptual representations. 
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2.1 Introduction 

We will use conceptual representations to specify a wide range of data structures at 
various levels of abstraction. The motivation in developing conceptual representations is to 
provide a specification language which serves as a good interface between programmers 
and the computer and also between users and i mul c mcntois . A "good* interface language 
should allow programmers to easily express and understand their intuitive concept of a data 
structure and how it behaves for various operations. For example, the language" of 
diagrams using boxes and arrows is a very good language in which people can exchange 
their intuitive ideas about the sharing relationships among objects. However, such a 
language is not rigorous enough for the computer to understand without many hidden 
assumptions. The specification language based on conceptual representations introduced in 
this chapter is rigorous and yet able to express graphical intuitions about data structures. 

Different degrees of awareness about the implementation of a data structure are 
required in the different activities of implementing a system such as the initial design, 
coding, and the subsequent evolution. Conceptual representations are flexible enough to 
express only the details which are important in each activity. As mentioned above, 
conceptual representations are not confined to specifying data structures. They are used to 
describe states of both procedural and data objects and also used to express views and 
summaries of behaviors of such objects. Examples of such conceptual representations win 
be found in the later chapters kg. Chapter 6 and Chapter 81 
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2.2 Conceptualization of Data Structures 

In this section, we explain syntactic constructs of conceptual representations using 
simple examples. The BNF syntax of conceptual representations is given in Figure 2.1 at 
the end of this section. 

2.2.1 Keywords and C-packages 

Let us consider a simple data structure, a cell, which contains information that can 
be retrieved and updated. In order to express a cell which has its contents, say 10, we use 
the following notation 

{CELL (contents: 10)). 

This is a conceptual representation of the cell. When this cell is updated with new 
contents, 12, its conceptual representation becomes 

{CELL (contents: 12)) 

A word "CELL" in the above conceptual representations is an example of the keywords 
which express the conceptual types of data structures. The keywords are always spelled in 
italic capital letters. 

In addition to keywords, another syntactic construct, conceptual packages 
(abbreviated as c-packages)* is used to express more detailed information about data 
structures. A notation "(content*...)" in the conceptual representations for cells is an example 
of c-packages. C-packages are useful to distinguish conceptually different kinds of 



I. The syntax of c-packages are borrowed from that of packages in PLASMA 
[Hewitt-Smith75, Hewltt77] 
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componenu of a data structure. For example, a node In list statctures of M$P has two 
conceptually different kinds of com p o n e nt s, the car-part and the cdr-part The following 
co nc e ptu al representa tion 

(NODE {ear. loiieSnlin 

"expresses a node whose car-part and cdr-part are K) and K, respectively, (ear: 10) and 
(erfr: 12) are c-packages. Selectors of packages (eg. tmr and edr) are always spelled in the 
lower case italic letters followed by a colon. 

When the details or spectf kxtton of some components of a data structure are 
unimportant, but their existence in the data structure need* attentfc>rt. Question marks may 
be placed in conceptual representations. For example, when we want t» express a isode 
whose car-part is 18, but cdr-part may be anything, 

(MOWKcr: 13) W« H) 

may be used. We call the question marks used m mo way dummt) dmtnt notations. 



2.2.2 C-sequences 

There are many data structures which are naturally viewed as a linear seque n c e of 
components at some levels of abstraction. Queues, stacks, arrays, tables and etc are 
examples of such data structures. To express such conceptual sequences of co mp o nent s in 
data structures, we use a syntactic construct, comctptMMl Mftwtw (abbreviated as 
c-sequencts)} 



1. Specifications of form in ALPHARDCWutf-et-aTO) are stated In terms of mathematical 
ob jeer* such as seouences and sets. 
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Let us consider queues to see how c-sequemes are used. Programmers envisage a 
queue as a linear sequence of elements which are enqueued at one end and dequeued from 
the other end. Suppose that we have a queue consisting of three elements, 1, 2, and 3, where 
1 is its front element and 3 is its rear element Using a c-sequence [1 2 3% this queue is 
expressed by the following conceptual representation. 

(QUEUE 111 3]) 

When a new element 4 is enqueued at the rear end of this queue, this queue is expressed as: 

(0C/H/S [1 2 3 4fl. 



2.2.S Unpack Operations and Dot Notions 

In order to express a queue which has an indefinite number (including zero) of 
elements, we use a c-sequence variable, say x, in conceptual r ep r e se n t ations as follows: 

[QUEUE [U]) 

»x is an abbreviation of the "unpack" operation on x. 

In general, !<«x»ras«ien> is equivalent to writing out a* of the elements of the 
c-sequence denoted by <«pr»«Jon> individually. For evampk. mppttit that x donates a 
c-sequence [2 3 4], Then 

U W ■ [UI2 3 4J] * [12 3 4] 
whereas 

[i x] * [1 [2 3 4]] * CI 2 3 41 
When y denotes an empty c-sequence [], 
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Thus {QUEUE [JyJ) 1$ equivalent to (QUEUE fl| whkh it the conceptual lepmentatton of 
an empty queue. 

Let us look at rnore ebborate examples of conceptual representations of queues 
which use unpack operations and c-sequence variables. The two conceptual representations: 

{QUEUE [6 U]) and QUEUE [U*V 

express a queue whose front element is 6 f ottowad by the dements of a and a queue whose 
last element is 9, respectively. Furthermore 

(QUEUE [U $ fyj) 

expresses a queue which has 8 as one of its elements. When the elements before and after 
8 (i.e. !x and !y) in the queue are uninteresting, the following conceptual representation may 
be used. 

(QUEUE [..*-.)) 

"..." inside the c-sequence is called a dot notation. In general, dot notations are used to 
indicate only the existence of an indefinite number (including zero) of elements whose 
specification is not important tea c-sequence or c- cottec tion . (Cf. ZZA) Dummy element 
notations may be used as elements of c-wjqoences. For example, a conceptual representation: 

{QUEUE p 3 4 5]) 

describes a queue whose front element is unknown ( or unimportant), and the rest of whose 
elements are 3, i and 5, in this order. 
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2.2.4 C-collections 

Another syntactic construct of conceptual representations is conceptual collections 
(abbreviated as c-collections) which are used to represent a conceptual group of components 
in data structures. C-collections are different from c-sequences in that the order of 
elements in c-collections is unimportant For example, a c-collection {2 3 7} is equivalent to 
both {2 7 3} and {7 3 2}. C-collections are also different from mathematical sett in that 
multiple occurrences of the same elements in c-collections age important For example, a 
c-collection {2 2 7} is not equivalent to {2 7 J. 

A simple example of conceptual representations using c-collections is 

(SET {3 4 5}) 

which expresses a data structure of the type "set" whose elements are S, 4, and 5. An 
indefinite number of elements of a c-collections can be expressed by the unpack operations 
and c-collection variables. Thus a general form of the conceptual representation for the 
data structure "set" may be expressed as 

(SETIW). 

C-collections may be described by using dummy element notations T and dot notations "..." 
in the same way as c-sequences. 



-24- 
2.2.5 Pattern Matching 

Unpack operations are extremely useful in pattern matching 1 of c-sequences and 
c-cottecttons. Below we win give basic examples of pattern matching. Instead of presenting 
the matching algorithm. 

Suppose that a c-sequence of four numbers (I 9 • 4} matches against the following 
patterns, where u, v, and w are pattern (or free) variables on c-sequence*. 



U) [1 Nli « avast ft* (91-41 

(2) [!v 14], v mast be [1 9J. 

(3) [far], wn^h[tll«| 

(4) [!u « !vj, u «*«? v mm* ft* [J 9] asji [4J, napteOmty. 

(5) [198 4!uJ, u *•*•«[]. 

Suppose that the same c-sequence matches against the following patterns, where M and N 
are pattern (or free) variables on numbers. 

(6) [M!u], M and u imut ft* 1 and [9 1 4], rnpaetimmly. 

(7) HuN), uwttfN m*rttK[l9tl*>i*,r* t p*cti**,. 

But [19 9 4] does not match against the fottowmg pattern; 

(8) [MNJ. 

Some patterns may have more than one matching case For example, when [19 8 4] 
matches against 



1. The use of pattern matching in our specification and verification techniques will be 
exemplified in the process of symbolic evaluation m Chapter 5. 
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(9) [1 "u M !v], there are three matching com*: 

Ca»e-l: u = [], M = 9, v = [8 4]. 
Cate-2: u = [9J, M = 8, V = [4]. 
Cate-3: u s [9 8], M = 4, v e []. 
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Fig. 2.1. Syntax of Conceptaal Representati«u i» BNF 

<conceptual-representation> s- { <kefword> ) | ( <keyword> <cowoepttttl'«orotttuentj> ) 

<keyword>u- 1 a word in th« mppmr emm Umiie f»nt 1 

<conceptual-con$tituents> ::- <an-*nUty> | <c-«equence> | <c-coBection> | <c-package-iequence> 

<an-enttty> ::- X a tinglm cvmxptmml tmtky, wkkk i* •fun a* netmr % 

<c-sequenee> ::- [ <juxtapotttk>n> ] 

<c-coflectton> n- { <juxtapotition> } 

<c-package-sequcnce> n- <c-package> | <c-package> «c-packagt-saquence> 

<c-package> ::- ( <selector> <conceptuaKotutttuents> ) 

< juxtaposition ::- <efcment> | <cfcment> <Juxtapc*ttk>n> 

<selector> ::- t on identifier in tht Itmtr mm Umlit font foUmmmi by « emlmt. t 

<element> ::- <empty> | <an-entity> | <c-iequence> | <c-cotlectlOR> | 

<c-package> | <unpacked-c-iequence> f <dot-notatfc>n> | pl ummy el e m e nt n o U tton> 

<empty> ::- t an •mpty Mring t 

<unpacked-c-»equence> ::- |<c-sequcnce> | !<c-»equence-vartabte> 

<dot-notation> ::- .„ 

<dummy-element-notaUon> u- ? 

<c-»equence-variabJe> ::- t on Utndftmr in tkt Ummr mm mm fmnt ft 
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2.3 Specifications of Data Structures 

In this section, we exemplify how conceptual representations are used in 
specifications of data structures. An abstract data type [Liskov-Zillej74] or a data structure 
is specified by the functionality (domains and ranges) of the applicable operations and the 
effects of these operations. If the data structure may be created by users, how it is created 
must be also specified. In specifying functionalities, a notation "error" is used to denote a 
set of error messages which warn users of operations that an error has occurred. We 
assume that data structures are not changed by operations which cause error messages. 

2.3.1 Queues 

As suggested in the previous section, we use conceptual representations of the 
following form to express a queue. 

(QUEUE [..]) 
A complete specification of queues is given in Figure 2.2. 



-» 

Fig. 2.2. A Specif tcatkm of Queues 

FUNCTIONALITY: 

i) CHCATE-QUiUKi -~ > 



H) ENQUEUE* fiftm* x tttm —> ftuu$ 

enqueues a new item at the rear end of the queue. 

HO DEQUEUE* ftt«u« — > tttm x qunu or error 

striata dequeue the front efcment of the queue. 
Uf the queue U empty, an error nteangt U produced. 



Iv) IS-EMPTYt etuut — > teotant 

checks wtwther or not die queue it empty. 

EFFECTS: 

<1) CREATE-QUEUEO > «*/«/* D> 

(2) ENQUEUE({0t/flt/X (M), A) > {QTJK/f fr AJ) 

(3) DEQUEUE((pt/«/« D)) > ERROR 

(4) DEQUEUE(f0t/KUK [A !*])) > <A , {QUEUE [UV> 

(5) IS-EMPTY«0C/«/« [))> > TOC/I 

16) IS-EMPTYWC/IUB [A M» -— > MIS* 
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2.3.2 Sets 

A typical use of conceptual collections in conceptual representation* is the data type 
"set". The following four operations are associated with the set type 

FUNCTIONALITY: . 

I) CREATE-SET: — > set 
•creates an empty set 

H) INSERTi element x set — ■> set 

.-tries to insert an element, 

Uf the element is already in the set, no effect 

Hi) DELETE: element x set — > set or error 

,-tries to delete an element f rom a set 
;if the element is not in tte set, error. 

iv) INT t element x set — > boolean 

.•checks whether or not an element to a member of a set 

The effects of these operations are formally described in Figure 23. Note that the 
membership of an element in a set to expressed succinctly by dot notations in c-conections. 



Fig. 2.S. A Specification of ScU 

EFFECTS: 

(1) CREATE-SETO ~ > {SET {)) 

(2) INSERTS {SET {U})) 

if x ■ { _ E ~ } — > {SET (W) 
</xHUE>} > (SKT {hE}) 



(3) DELETED, {SET {|x}» 



If x « «y E Is} > (SBT iff Ml 

IfxiM-E-} — -> KRJW* 



(4) INTCE, {SET IU))) 



If x ■ { -. E _ } — ■> m/« 
*/xi«{„E-.J -— > FALSE 
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2.3.3 Arrays 

The following five operations are associated with the array type. 

FUNCTIONALITY: 

I) CREATE-ARRAY: integer x Integer •—> atrof or error 

jtries to create an empty array with the specified lower and upper bounds. 
;the first integer should not be greater than the second ipitegefw, 

if) STORE* array x integer x Item — > array or error 
^rte$ to store an Item with the specified index 
*he index should be within the bounds. 

Hi) FETCH: orroy x Integer — > item or error 

;tries to fetch an item with the specified index 
;the index should be within the bounds. 

iv) BOTTOMt array —> Integer 
returns the lower bound. 

v) TOPi orroy — > integer 

returns the upper bound. 

To express arrays, we use conceptual representations of the following form: 

{ARRAY (W I) (Mf fc h) UkmontK {«p AJ-.J)) 

where I and h are the tower and upper bounds, respectively, and an item A with the index I 
is expressed as a c-sequence p A] in the c-collecUon of the {eiomemu ) c-package. The 
effects of the operations applicable to an array is given in Figure 2.4. 

Multi-dimensional arrays can be expressed easily by modifying c-sequences In 
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Fig. 2.4. A Specification of Array* 

EFFECTS: 

(1) CREATE-ARRAYfl, h) 

if UK — > {ARRAY {Urn nVdtkWUUmmKi))) 

lf\>K ~> BQm Mmmimtwr. 



(2) STORE((/WR>«y U*« I) (W^fe h) W.m«««: {|x}», I, A) 
l/i>hori<l, — > EJWOJt ;*~»4 
*/ I S I 5 h and x « {!«1 [i t}.Ja2} <«4«» **• N^Wmmm •I.Wy #*i*«. 

— > (4**4? (W I) MgiKHUUmm** {t«l ft A] N2}» 
</ I S » S h and x i* { ... [I ?] _. } .«*«, t A* <-** «<«m«M 4mi mm «ste. 

— > CifAJtUr CW I) (M,fc h) Ur.iiw*r {Jk p Xjbft 

(3) FETCH((/1RR/4r (W I) (kigk: h) (■t«» < «i; tfx& *» : ,? 

</ I > h or i < I, —> ERROR Mmmd mrmr. 

If l*i*h and x-{„[JB]„} — > B 

i/ I S i * h anrf i<|.pfl-) ~> CTMW ^Im tfe HA 4mmm it mm fmmmi. 

(4) B0TT0M<(j4ftJMr (W I) (M*fc h) WmmMi: {-}»)—> I 

(5) TOPUARRAY <W I) (M*fc h) itUwumu: {-.}))) — > h 
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the UlementK ) c-package to include more than one index. For example, a two-dimensional 
array may be expressed by a conceptual representation of the following form 

[ARRAY Horn: ») (*,*; h) i*Um«*x {„ p J.*J * }» 



2.3.4 Symbol Tables 

As an example of specifications for more complicated data structures, we give a 
specification of symbol tablet [Guttag75, London-et*D6]. Symbol tables are of ten used in 
writing compilers for programming languages which have ALGOL-Hke block structures. A 
symbol table records pairs of an identifier and its attribute. The same identifier may have 
different attributes depending upon where, the identifier Is used m the Mock structure. We 
assume the following six operations are applicable tea symbol table. No operations except 
ENTER-BLOCK are allowed before the most global block U entered. The creation of a symbol 
table does not imply the entering of the most global block. 

FUNCTIONALITY: 

i) CREATE-SYMBOL-TABUt — > sjmboHabk 
creates an empty symbol table. 
-jno block has been entered yet 

H) ENTER-BIQCK* symbol-table — > symH-takU 
;set up a new local naming scope. 

Hi) LEAVE-BLOCK: symbol-table — -> symboi-tablt or error 
;tries to leave the current block. 

;if the current block is outside the most global one, then error, 
jotherwise discard the current block and reactivate the most previous scope 
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iv) AOOt symbol-table % id % attribute — -> symbol-table or error 
;tries to add a pair of an identifier and its attribute. 
;if the current scope is outside the most global block, then error. 
;if the identifier Is already declared in the current block, then error. 

v) RETRIEVE: symbol-table x id — -> attribute or error 

;tries to retrieve the attribute of an identifier in the most recent 
;bkxk in which the identifier is declared. 
4f H is not found, then error. 

As a c oncep tua l rep r es e nt a tion for the symbol table, we use the following notation: 

{SYMBOL-TABLE [|x]). 
x is a c-sequence whose elements are empty or c-packages of the form 

fbUehjm 

which conceptually represents a block. The order of c-packages in x, corresponds to the 
order of blocks. That is, the last c-package in x corresponds to the most recently entered 
block, y is a c-sequence whose elements are pairs of an identifier and its attribute. Such 
pairs are expressed by a c-sequence For example, suppose that hi some block identifiers A 
and B are declared to be real and integer, respectively. Thai the conceptual repr e senta tion 
for this symbol table looks like: 

SYMBOL-TABLE [ „(«•«*;[- {A real] - [B integer) J^ J&. 

Using conceptual representations of this form, a specification of symbol tables is written as 
depicted in Figure 2JL 
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Fig. 2.5. A Specification of Symbol Tablet 
EFFECTS: 

U) CREATE-SYMBOL-TABLEO — > SYMBOL-TABLE U) 

(2) EKTER-BLOCK((SYMBOL-TABLBim) — > (SYMBOL-TABLE JJy Week: [»J> 

(3) LEAVE-BLOCK((SKMBOL-r/JBLE [])) — > ERROR 

;feaving the most global block (without entering). 

(4) LEAVE-BL0CK((SyjlBOI.-ri«»L*[|w(Modk:[-.J)») — > {SYMBOL-TABLE [|w]) 

<5> AD0((5FM BOLT ABLE [)), ID, AH) —> ERRO/t 

adding an id-attribute pair without ending the moat global block 

(6) AOOUSY M BOL-TABLE [lr (block; [\p4rt)))), 10, ATI) 

if pairs « [ ... (lb f ] ... ] — > ERROR <ID is already declared In the current block. 
if pairs #[... [ID fl _ ] 

— > {SYMBOL-TABLE [|r (Ueefc tlpsire [XD ATTTj)P 

(7) RETRIEVE((SK JWBOL-r/1BL« [|t]), ID) 
(^ti*UfBladb[4iprM)Lj — > SJtflOJt 

;the identifier is not found in an; blocks. 

if\ - [...(atecfc C_[ID ATTJ W) M and y # [..fUfcfc j-JXD fjjkj — > ATT 



2.4 Relationship to Other Work 

In this section, we discuss the relationship of our specification techniques for data 
structures presented in this chapterVto some Otner work in the sainearea^'W 
to consider an algebraic axiomatic approach and an abstract model approach because these 
two approaches are in dear contrast to ours and abo weQ studied. An excellent survey of 
specification techniques for abstract data types is found m 0L4*koT-ZiHes76j. Other 
approaches such as Parnas's "state machine modeT [Parnas7$ ate also revi ewe d in 
[Liskov-ZillesTS]. 

■2.4.1 Algebraic Axiomatic Approach 

Algebraic axiomatic techniques have been studied by a number of researchers 
[Zilles74. Spitzen-WegbrettTS, Guttag75, Wegbreit-SpitzenTBl In this approach, the effects 
of operations on an object of the data type being specified are expressed in terms of 
equations of the operations, to compare their approach with ours, we present two 
algebraic axiomatic specifications, on? ./©j queue* (whicb is a modified version of 
[Spitzen-Wegbreit75]) in Figure 2.6 and the other for symbol tables (which a slightly 
simplified version of [Guttag75]) in Figure 2.7. 

All the axioms given in their specifications in Figure 2j6 and Figure 2.7 are easily 
derived from our specifications of queues in Figure 22 and symbol tables in Figure 23. 
[For the derivation of the axiom (5) in Figure 2.6, see Appendix I] We believe that 
specifications using conceptual representations are often easier for programmers to both 

1. In this chapter, we assume that data structures or data types are always used in serial 
computations. Our techniques for data structures (or abstract data types) with parallelism 
and side-tffects will be pr e sent e d tn the later chapters. 
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Fig. 2.6. An Algebraic Axiomatic Specification of Qveaes 
FUNCTIONALITY: omitted. 

AXIOMS: 

(1) IS-EMPTY(CREATE-QUEUEO) 'TRUE 

(2) IS-EMPTY(ENQUEUE(Q, A)) m FALSE 

(3) DEQUEUE(CREATE-<JOCUE()) • ERROR ptfmpU f itqmmt mm empty «mm 

(4) If IS-EMPTY(Q) then DRjUEUE(EMQUEUEtQ, A)) - <A, Q> 

(5) if -.IS-EMPTY(Q) A 0O)UEUE«) « <B, Q^ 

then DEQUEUE(ENQUEUE(Q t A)) - <B, ENQUEUE(Q\ A» 

construct and understand than algebraic axiomatic specifications, because in the conceptual 
representation approach we describe directly and expUdfo what effects take place in data 
structures (at the conceptual level) when the operations are applied, whereas the algebraic 
axiomatic specifications describe the effect* of the operations Indirectly and implicitly in 
terms of relations (or equations) among the operations. In particular, the axiom <§) for 
symbol tables in Figure 2.7 is expressed in terms of a recursion of RETRIEVE. Such indirect 
specifications are often difficult to grasp. Thus the author and reader of an algebraic 
axiomatic specification of a data type may be less confident as to whether or not the 
specification completely describes the desired properties of the data type 

Recently a serious problem in the algebraic approach has been pointed 
out(Majster771 The problem is that there are some classes of abstract data types which 
cannot be specified by a finite set of axioms for the operations (equations of the 



Fig. 2.7. An Algebraic Axiomatic Specifkatiea of Symbol Tables 

FUNCTIONALITY: omitted. 
AXIOMS: 

U> LEAVE-BUXXfCREATE-SYMBOL-TABUO) ■ ERROR 

(2) LEAVE-BLOCK(EHTCT-BLOCK(«yiiil*)) - tywi* 

(3) LEAVE-BLOCK(AOO»ywUb, Id, ittrs)) ■ t£AVE-RU)Crtsr»d«) 

(4) RETRIEVE(CREATE-$YMB0L-TA8LE0, Id). ERROR 

(5) RrTRIEVE(ENTER^LOCK(^i^*),W)«l«TIU«V«kyi#*,M) 

(6) RETRIEVE(ADO(tym*«b, M, atim), Wl) 

(f id-Mi, 

thtn fttrt 

«fre KEIHlfc¥UsyMM>, idl) 

operations). To avoid this problem, they must use oxfoM jdtaute instead of Infinitely 
many axioms. This violates the ftnfteness of thY axiom set imich is ah important 
assumption of the underlying theory for *lg«brafc soedFtatk* techniques. Our conceptual 
representation approach does not have iuch a problem, because, as mentioned above, our 
techniques describe explicitly what effects the operations cause to data structures. (In 
appendix II, a data type which cannot be expressed by a f into set 'of algebraic axioms of 
operations is specified by using concepttwi representation*.) 

Furthermore, the current algebraic and axlomatk. technksoes do not capture an 
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important difference between data structures without tide-effects and data structures with 
side-effects. (This difference will be explained in Chapter 1) As will be seen in Chapter 
4, the specification technique using conceptual representations can easily express this 
difference. For further discussions on the algebraic approach, see Section 4 AS. Chapter 4. 



2.4.2 Abstract Model Approach 

B. Liskov and V. Berlins [Liskov-BerzinsTT] have been developing an abstract 
model approach in the area of specification of abstract data types. The construction of its 
mathematical foundation is underway [Berzinsttl Irt this approach, first a certain set of 
well established data types and mathematical objects tag, sets, sequences, tuples and etc) is 
chosen. Then new abstract data types are specified m terms of such chosen data types or 
already defined abstract data types. 

As an example, we give an abstract model specif fcattan of arrays cited from 
tLiskov-Berzins77] in Figure 2.8. Objects of the type irrarft] are represented by the 
following tuple: 

tupleOow: integer, 
high: integer, 
elements: scqucnc e &u pte&ndex: integer, value tBl 

Comparing the specification in Figure 2.8 with the one given in Figure 2.4 which is based 
on the conceptual representation*, one to struck by the similarity. In fact, in representing 
objects of a new data type, the roles of sequence, sets and tuples in their approach 
correspond to those of c-sequences, c-collectiom and c-packages in our approach. However, 
in the abstract model approach, the operations applicable to objects of a new data type are 
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Fig. 2.8. An Abstract Model Specification of Arrays 



FUNCriONAMYi omitted. 



OPERATIONS: 
alkx(il, 12) - 



if II s 12 then {loir. 11, high: 12. elements: o} 
efae errorfbad array size") 

to in m tu mm •mptf Hf i nw e* pad {*.[ 



• tmplm. 



bot to m ( a) 



a;low 



top(a)- 



a.high 



storefc, i, a) 



if a.tow s 1 $ aJiigh 

then { tow: a.low 

high:a.high 

dements: addfj)rst({index: i, value: x), a^tements) } 



fetch(l, a) 



getvaKelements, i) - 



if a.kw s i 2 a.high then getvaKa^lements, i) 
else errorf index out of bounds") 

if length(elements) > then 

if elemenb|.index » i then etementS].vatue 
ebe getvaKbutfiin^hu'wuts), I) 
else UNDEFINED 
setementsj mm* tttmfim Imm/rt. iifwti i t n m tU by Vtemenu" 
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specificed in terms of procedures defined on pre-defined data types. Getval, addf irst, and 
butfirst in Figure 2.8 are examples of such procedures. In the conceptual representation 
approach, we do not use such procedures in specifying the effects of the operations. 
Instead, we rely on pattern mechanisms of keywords, c-sequences, raHecttons and 
c-packages. which have been exemplified by a number of specifications. 

As was pointed out in the previous subsection, our approach is extended easily to 
cover data structures with side-effects. The extendabWty of the abstract model approach 
remains to be seen. 
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3. Behaviors of Aotors (A Modol of Computation) 



In this chapter, we introduce the model of dttermlnlstic computation on which the 
discussion in the rest of this thesis is based. The first section mainly contains definitions 
and intuitive accounts of various concepts and notations employed in the model of 
computation. The second section describes the characteristics which must be considered in 
trying to construct formal specifications of computations in the model. This section 
contains the classification of interactions among actors. 
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3.1 The Actor Model of Computation 

The fundamental objects in our model of com puta tion are actors. Computations 
are carried out through message passing between actors. An actor is a potentially active 
object (procedure) which becomes active when it receives a message. Each actor decides 
itself how to respond to messages sent to it No actor can treat other actors as objects to 
operate on: it can only send a message to other actors.' 

Messages are also actors. An actor may be created in the course of computation or may 
exist in the beginning of a computation. More than one transmission of a message at a 
time in an actor system may take place. 

A collection of actors which communicate and cooperate with each other in a goal 
oriented fashion can be implemented as a single actor. A system of actors can model 
various kinds of information processing schemata from ordinary sequential arithmetic or 
symbolic computations to highly distributed parallel computations including computer 
networks of varying scales. Furthermore, it can model problem solving activities by a 
society of expertsEHewitt771 

A number of concepts in programming systems can be captured by simple concepts 
in the actor model of computation. For example, traditionally different kinds of entities 
such as data, data structures, files, and procedures are unified as a single kind of object, the 
actor. Control structures such as recursion, iteration, and coroutines can be viewed as 
particular patterns of message passing fHeWitt771 Furthermore, calling a procedure, 
returning a value, retrieving and updating data structures, and synchronization and 
communication of cooperative parallel processes are achieved by message passing. 



1. For example, to get the i-th element of an array A, an U-ifc) message is sent to A instead 
of doing a fetch operation A[il 
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An implementation of the actor model of computation has been realized as a 
programming language PLASMA[Hewitt-Smith75, Hewitt771 The syntax of PLASMA is 
so designed that its underlying semantics is transparent : 

The above intuitive account of the model of computation will be made more 
precise below. 

S.I.I Actors 

An actor consists of two parts, script (action) and acquaintances. Its script is a 
description of how it should respond to messages sent to it Each actor has a fixed set of 
messages by which it can be activated. When a message that does not belong to this set is 
sent to an actor, the response of the actor is undefined. The acquaintances of an actor are 
a finite collection of actors that it directly knows about. An actor A can send a message 
directly to an actor B only when B belongs to the acquaintances of A. The script of an 
actor can be realized by a PLASMA program for the actor. The acquaintances of a newly 
created actor C are the set of actors which are denoted by free identifiers in the PLASMA 
program for C at the time of creation. 



3.1.2 Events 



An event E is defined to be the rtctlpt of a wssage 1 moor M by a target actor T- 
The event E is expressed by a notation of the form 



I. We use the terms "receipt" and "arrival" of a message interchangeably throughout the 
thesis: 
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l T <«- M J. 

A message contains a request of what the target actor is asked to do and it may also 
contains a continuation actor which is the destination where the reply to the request is 
supposed to be sent. Messages are often expressed by notations of the form 

[requeu: < requ«st> reply-to: < continuition> l 

The request usually consists of a tag which indicates a task to do and the data necessary to 
accomplish the task. PLASMA packages are often used as requests. For example, to request 
a queue-actor to enqueue some actor A at the end of the queue, the package {enqueue: A) is 
used. To request a queue-actor to send back its front element, the package {dequeue:) is 
used. The continuation actor may be omitted in the message when it is unnecessary. For 
example, when the purpose of a message is to return the result of a task, or the reply to a 
request, the message need not contain a < continuation> . In such cases, messages are expressed 
by notations of the form 

[reply: <r§sult>] 

When a continuation C in a message is unimportant or obvious from the context of 
discussion, we make only the request part explicit in expressing an event. So the following 
abbreviated form is used 

[T <= <reguest>J for £T <« [requeu: <r*gtMst> reply-to: C]3- 

Furthermore, when it is obvious from the context that a message contains only a replying 
result, we use the following abbreviated form. 
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[T <« <r§juQ>] for [T <«= \r*ply- < retult> Tf. 

Note that the above abbreviated forms use single shafted arrows "<-" instead of double 
shafted arrows "<--". In the subsequent presentation of this thesis, t |ht terms "request" and 
"message" will be used interchangeably when we art not interested in die continuation in a 
message. 

A primitive event is an event which activates exactly one immediate reply without 
causing any intermediate events. From this definition, we can define primitive actors. A 
primitive actor is an actor which always causes a primitive event when it is sent a message. 

As we have noted above, different control structures in programming languages 
are viewed as different patterns of message passing in the actor model of computation. In 
fact, such different patterns of message passing correspond to different patterns of 
continuation in messages. The patterns of continuation for recursion, and iteration are 
found in [Hewitt77] and for coroutines in [Greif-HewittTSl The fact that continuations are 
sent together with requests allows the unification of control flow and data flow into a 
universal flow of information, message transmission. Consequently, this unification allows 
us to describe computations solely in terms of events. 



3.1.3 Computations 

A computation is defined as a partially ordered set of events, where the ordering is 
strict and transitive. A physical intuition for the ordering II that an event E precedes 
another event E\ We call this ordering the precedes order and denote it by "->". Then a 
computation is a pair <Ev, "-->"> where Ev is a set of events. The strictness of the ordering 
imposes the constraint that any event E does not precedes itself : 
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V E, -*(E --> E). 
The partialness of the ordering allows that some events Ej and E : do not precede each 
other, which means that Ej and E , may take place concurrently. We assume that each such 
ordered set of events always has the maximal events in it. This means that every 
computation has a set of initial events. 

Our assumption to model physically realizable computations requires two kinds of 
finiteness properties. First, for any two events Ej and Ej which are ordered by "-->", only 
finite numbers of event can take place between Ej and Ej. I.e, the set {E|Ej --> E --> E.} is 
finite. Second, each event E has finitely many immediate successor events. These two 
finite properties do not rule out non-terminating computations: they only exclude infinitely 
fast computations.' 

The precedes ordering has two suborderings which reflect more detailed physical 
properties of computations. Suppose that E is an event in which a target actor T receives a 
message actor M. Then the event E triggers a response (or action). This response is a 
finite set C of events. We can view that the event E activates the events in C. Thus we 
call this type of ordering the activation ordering and denote it by "-act->". So V EE in C, 
E -act-> EE. The activation ordering is intended to describe the notion of causality in 
computations. 

Suppose that more than one message is sent to a single actor A In a computation. 
In our computation model we assume that one message arrives before another. I.e., no two 
messages arrive at the same actor simultaneously. Since each arrival of a message at A is 
an event by definition, if we fix a target actor, we can always introduce an ordering among 



1. Hewitt and Baker gave an proof for the impossibility of such infinitely fast 
computations in [Hewitt-Baker771 
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events which have A as a target actor by arrival Utu. We catt this ordering the arrival 
ordering with r**p«e* <• A and denote toby "»wi^>a*. 

The important property of the arrival ordering to that it is a tetat order: each 
event in a computation can have at most one immediate successor event in terms of the 
arrival ordering, whereas it may have more than one imme diate s u c c e s sor event in terms of 
the activation ordering. 

A nested activity to a computation starting with a request event RQ,of the form 

fT <=x Ireauest: <reotif t> reply-tm <centin qetipn> fp 
and ending with the corresponding reply event RP 

The set of events consisting of the nested activity to the set: 

{E I E - R<tv E - RP v(RP -> E A E ~> R<$ } 

When a continuation is not contained in the message, the nested activity is undefined. 

There are many activities hi operating systems and distributed computing systems 
that are not nested. It should be pointed out tliat one may find manv non-nested .activities 
in the real world. The model of a post of f ice given in Chapter 8 to an example of such 
non-nested activities. 
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3.1.4 Level of Detail 

The behavior of an actor system can be described at varying levels of detail. 
Computing the factorial of 3 can be viewed as a process to input S and to output 6 at some 
level of detail. At this level of detail, an iterative way and a recursive way of computing 
the factorial of 3 are viewed as the same computation. Some difference between two 
implementations of the iterative factorial may be detected at some finer level of details. 
There may be many implementations of an actor which satisfy a given specification. Such 
implementations are viewed as the same Implementation at one level and different ones at 
another level. At a finer level, some computations which may be viewed as a serial 
computation at a less fine level may be revealed to be parallel compulations. 

In order to describe the behavior of an actor system we need to choose a level of 
detail according to the purpose of description. The description of the behavior of an actor 
system at the lowest level of detail is given as a computation <Evfl, "->"> where Evq is a set 
of all events which take place in the actor system. A level of detail is decided by criteria 
with which a subset Ev is chosen from Evq. Since any events Ej and E: in Ev are also in 
Evq, if Ej and Ej are ordered by "->" in Evq, the same order relation holds in Ev. Thus a 
partially ordered set of events Ev is a "sub'-computation of Evq. Choosing a subset from 
Ev is done with various criteria which are decided by the purpose of description. For 
example, first we select actors from the set of all actors in the system, and then all events 
where the selected actors are involved as targets or messages are chosen from Evq. Another 
example of the criteria is to select events which meet some patterns such as the beginning 
and ending events of nested activities. 

The notion of primitiveness defined in the previous subsection is relative to the 
level of detail chosen. The event where the factorial actor receives S is primitive at the 
level of detail where no events taking place before the arrival of 6 at the continuation are 
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counted. An event where a data base receives a query can be viewed as a primitive event 
at a very high level of detail. Thus a data base can be considered as a primitive actor at 
that level. 



3.2 Time Variant Behavior* of Act ore 

In this section we discuss the characterittia of individual actors which must be 
taken into account in formally specifying the behavior of abactor tystem. 

3.2.1 Pure Actors and Impure Actors 

Atl actors are classified into two categories depending upon their behavior. Actors 
which belong to one category never change their behavior. They always give the same 
reply to the same request. They are called pure actors. Actors which belong to the other 
category are called impure actors and their behavior may change with time. Thej do not 
always give the same reply to the same request The following mere precise definitions are 
given in terms of nested activities. 1 

An actor T is pure if, for the same message M, the event [T <-- M J 
always causes (precedes) the same reply event 



I. The definitions can be viewed as behavioral definitions of immutable and mutable 
objects.' 
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An actor T is impure (not pure) if there is a message M such that the event 
|[T <== M]| does not always cause (precede) the same reply event. 

The "sameness" in the above definitions is used in the following sense: two actors are the 
"same" if they are behaviorly equivalent} Two events are the same if they have the same 
target actor and the same message actor. 

From this definition, it can be said that a pure actor behaves like a mathematical 
function. An actor which generates random numbers is impure because it returns a random 
number in response to the same message {next-random-number:). A cell-actor is another 
example of a simple impure actor. A cell-actor accepts a message (update: < n«w-conUnt> ) 
which updates its contents and a message (contents:) which retrieves its contents. A 
cell-actor may change its behavior because it can give different answers to the (content*?) 
message, depending upon what it contains at the moment. An actor which behaves like a 
function + is a pure actor. The plus-actor always returns the same number, which is the 
sum of two numbers sent to it. Another example of a pure actor is a sequence-actor. One 
can retrieve elements of a sequence-actor, but one cannot change its elements; instead a 
completely new sequence-actor must be created. So a sequence-actor is pure. 

3.2.2 Pure Queues and Impure Queues 

To illustrate the difference between pure actors and impure actors, let us consider a 
pure actor and an impure actor, both of which behave like a queue. Both pure 
queue-actors and impure queue-actors accept the same two kinds of messages: one is (nq: x) 



1. For example, number actors which behave like 1 are behaviorly equivalent each other, 
but their identity may be distinct. The LISP functions, EQ and EQUAL, are impure and 
pure, respectively. 
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which is a request to enqueue a new elements x, and the other is {dq:) which is a request to 
take out the front element of the queue and return it with the remaining queue. However 
if the queue is empty, it returns a complaint message (exhausted.). The important 
difference between a pure queue-actor and an impure queue-actor is whether or not a new 
queue-actor is created when {nq: ...) and W?:) are sent. When {nq: x) is sent to a pure 
queue-actor PQ, a new pure queue-actor PQ,' which has x as the last element of the queue is 
created and returned. The original queue-actor PQ, still has the same elements as before. 
When (nq: x) is sent to an impure queue-actor IQ, x is absorbed inside IQ,and enqueued at 
rear of the previous elements. So IQ, itself is extended arid returned. No new queue-actors 
are created. (See Figure 3.1.) 

When (dqi) is sent to a pure queue-actor PQ, (which is not empty), a new pure 
queue-actor PQ) whose elements are all elements of PQ, except the front element of PQ, is 
created and the front element of PQ, and the new pure queue-actor PQ) are returned. 
Again the original PQ,is intact and has the same elements as before. When (dq:) is sent to 
IQ,(which is not empty), then the front element of IQ,and IQ, itself which now has the rest 
of the original elements are returned. No queue-actors are created. 

It might be helpful to see a LISP analogy in understanding this difference 
between pure queues and impure queues. Suppose that a queue is implemented as a list L. 
Then sending (nq: x) to a pure queue-actor corresponds to (append L (list x)), whose result is 
a totally new list constructed from a copy of L and x. Sending (nq: x) to an impure 
queue-actor corresponds to (rtconc L (list x)) whose result does not consist of a copy of L. 
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Fig. 3.1. Behaviors of pure queues and impure queues 
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3.2.3 Sources of Impurity and Uses of Impurity 

The change of behavior of an actor A is caused by the change of information 
used in computing the reply for a request to A. The change of such information is caused 
by the computation taking place before the reply event occurs. 

Roughly speaking, the sources which may change the behavior of an actor A can 
be divided into two kinds. One is the activation of A initiated by messages which have 
been sent to A. The previous activations of A change the information stored inside A. For 
example, a random number generator usually keeps some internal values used to generate a 
random number. For the generation of the next random number, such internal values are 
changed during the generation of the previous random number. In the case of impure 
queue-actors, the history of the previous enqueuing and dequeuing operations determines 
the reply for the current dequeuing request. 

The other kind of source is the computation initiated by messages which are not 
sent to A, but to some other actor B. When the computation initiated by a message sent to 
B changes information shared by both A and B, the subsequent behavior of A may change. 
Sharing of information sometimes happens inadvertently. When an actor A is created, 
some internal constituents of A might become known to other actors outside. For example, 
suppose that a new array-actor A is created by extending the upper bound of an existing 
array-actor B. If B receives a request to change one of its elements, the computation 
initiated by the request will change the subsequent behavior of A, because all elements of B 
are shared by A. There is another way in which internal constituents of an actor A become 
accessible. After an activation of A, the some internal constituents might be released 
outside as a result of the activation. Such released constituents become directly accessible 
from outside and information stored in them could be changed without sending legitimate 
requests to A. 
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Uses of an impure queue-actor are "destructive" in the sense that each enqueuing 
or dequeuing messages sent the actor changes the current status of the queue. If one wants 
to update the queue and stilt keep the previous status of the queue, the behavior of pure 
queue-actors is desirable even if it is costly in terms of both space and time. Sometimes the 
impurity of actors are necessary. For example, in order for concurrently running processes 
to communicate with each other, they need some actor which behaves as information 
storage through which they may exchange information. Such information storage may be 
contained inside each process or external common storage to which concurrent processes 
have access. This kind of impurity of actors is indispensable for communicating parallel 
processes. 



3.2.4 Four Types of Interactions between Actors 

Suppose that an actor M is sent as the request part of a message to a target actor 
T. This event initiates a computation where M and T are involved [i*. an interaction 
between M and T]. After this computation, there will be no changes in the behavior of M 
or T if both M and T are pure actors. If M or T, however, are impure actors, the 
subsequent behavior of M or T may be different. Interactions between two actors M and 
T are classified into four types, depending upon the presence or absence of change in their 
future behavior. 

No-Change-Tvpe: Neither M nor T change their behavior. 
The interactions initiated by the following events: 

[factorial <■ 3] 
£cr«at«-array <■ 4 J 
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[ merge <s [ARRAY- 1 ARRAY-2]] 

are examples of this type. The objective of tiiis type of interaction is creation of 
new actors. Neither the tectorial actor nor the number-actor 3 change their 
behavior, but the result of the? computation, a tra nb er - acior 6, is created and 
returned. The createoarray actor alwayscreates an art* y^of the st2e specified by the 
request message. The mare* actor creates a new sorted arrays whttse etements are 
those of the two sorted arrays ARRAY-1 and ARRAY-2. In this case, neither 
ARRAY*! nor ARRAY*! do not change. 

Target-Change-Ty pe T changes its behavior, but M does not 

This type of interaction often takes places to modify information stored in actors 
which behave like data structures. For example, 

[CELL <■ Updie: A)] 
[IMPURE-QUEUE <•<**•«*«: B)] 

are of this type. The behavior of A or B do not change after the interactions. 

M essag;e-Change-Ty pe: M changes its behavior, bat T does not 

Examples of thi* type of interaction are initiated by events such as: 

[tort <» ARRAY] 
[empty <* IMPURE-QUEUE]. 

When an array-actor ARRAY is sent to the tort actor, the same array-actor ARRAY 
whose elements are sorted is returned. In a simitar way, IMPURE-QUEUE is emptied 
but the empty actor does not change its behavior. 
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Target-Message-Chanee-Type: Both M and T change their behavior. 

Examples of this type of interaction are often found in situations where some 
information is removed from one actor and transfered to another. In Chapter 8, we 
will model the activities in a simple post office in terms of actors. The interaction 
among customer actors, collector actors, and a mail box actor in the model is of this 
type. 
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4. Specifying Serial Computations 



In this chapter, our specification techniques for serial computations are presented. 
Since our model is so constructed that serial computation is naturally extended to parallel 
computation, most of the concepts, notations, conventions and techniques introduced in this 
chapter are not only valid but also necessary for the specification and verification of 
parallel computations. In the first section, we introduce bask tools for describing the time 
variant behavior of actors. In the second section, we briefly discuss the role of conceptual 
representations in our model of computation. In the third section, our specification 
language for serial computations is explained and some issues of specifications related to 
"side-effects" are discussed. In the fourth section, examples of specifications written in our 
language are given. 
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4.1 Capturing Time Variant Behavior of Actors 

In order for a formal specification language to be effective for our model of 
computation, it must be able to describe the time variant behavior of actors. The ability of 
our specification language to deal with this aspect of actor behavior is based on concepts 
introduced in this section. 

4.1.1 History of Messages and States of Actors 

As we have seen in the previous chapter, one source of the lime variant behavior 
of an actor is the history of computations initiated by messages sent to the actor. If the 
whole past history of messages sent to an actor A is known, the subsequent behavior of A 
in response to a given message should be predictable. Thus, it is desirable to know the 
history of messages to specify the behavior of A. However, It is not practical to enumerate 
all possible histories of messages. Two actors with different past histories (sequences) of 
incoming messages sometimes show the same subsequent behavior. Thus we can partition 
the set of histories (sequences) of messages sent to A into equivalence classes according to 
the subsequent behavior of A. By such equivalence classes, we can define the notion of 
states of an actor. That is, the state of an actor A at a given point in time is defined as 
equivalence classes on the past histories (sequences) of messages sent to A. If A is in the 
same state at a different time, the subsequent behavior of A will be always the same. 

The state of an actor which behaves as an information storer is often defined by 
the contents of the stored information. For example, the state of a cell-actor C at a time is 
defined by the contents B of the cell. This definition of states is a special case of our 
definition by equivalence classes on past message histories. For the contents of the cell can 
be viewed as the most recent update message (Kpfaw: B). The (updat*,: B) message 
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represents the class of histories (sequences) of messages sent to C which have an Update: 8) 
as the most recent update message. 

Some kinds of states are not naturally expressed by the contents of stored 
information. For example, states of a data base which is being accessed by a number of 
concurrent processes are not expressed naturally by some stored information in the data 
base. The states where processes are updating or retrieving information in the data base 
may be expressed as certain monitoring mechanisms attached to the data base, but such 
mechanisms are dependent on the implementation oftHe data bale. When the states of a 
data base are defined externally |i.fe independently af Irnplemtnt ationV our definition of 
states is quite useful. The state of an air line reservation iflttm discussed in Chapter 6 and 
that of a post of f ice Hi Chapter 8 are examples of states of actors which are access ed by 
concurrent processes. 

Equivalence relations which determine states (t.e. equivalence classes) are chosen 
according to the purposes and level of the detail of the specification. Sutes which are 
different at some levels of the detail of the spectflcatkm may be the same at other levels. 

In Section 6.4, Chapter 6, we will discuss an alternative way of defining states of 
actors by continuous functions. 

4.1.2 Situations 

To incorporate the notion of states into the formalism for specification and 
verification, we need a notion of situations. A situation is the local state of an actor system 
at an instance of the local time. 1 A notion of situations which assumes the global state and 
global time reference has been proposed in the area of Artificial 



1. We will discuss the local time in detail in Section 612, Chapter & 
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Intelligcnce[NtcCarthy-Hayes69, Hewitt75l Our model of computation allows parallelism 
which is realized by concurrent message passing. Since instances of concurrent message 
passing (i.e. events) may take place totally independently, it is quite unnatural to assume the 
global time reference and global states of the system. [Local computations carried out by a 
PDP-10 at CMU are irrelevant to computations carried out by a PDP-10 at Stanford even if 
two computers are connected through the ARPA network.] 

In our formalism, states of actors and actor systems are always used with reference 
to situations. From this viewpoint, situations can be considered §4 .references of the local 
time. For example, the contents of a cell-actor C changes from time to time according to the 
update messages which have been most recently sent to C. Suppose that the contents of C 
is 3 in a situation S where C receives {update*. 4) message. Theft in^hetiext situation S* 
where C receives the message (content*:), the contents of C is 4. {See Figure 4.1) 

By using a symbol S to denote a situation, we express the contents of C in the 
situation m the following manner 

{conuntt C) « 3 in S 

We call a symbol such as S, which is used to refer to a situation, a situational tag. 



Fig. 4.1 





[C <= fapiato: 4)] 
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Uses of situation*! tags considerably increase the expressive power of our 
formalism. For example, suppose that we have two impure oueiie-actor*, queua~l and 
quoue-2, and that some event takes plac* in a situation &_ Let S^ denote the 
situation after that event Then the auestkw ar^ assertion of whether or not the length of 
quw^l is equal to that of qtw»»-2 in Sp^ U SWtttd i* rellows: 

{length quaiM-1) * {length queue-2) in S—^ 

By distributing the situational tag S po$t , the same statement can be made in the following 
two different ways: 

{{length queue-1) in S^ - <U«n#*A queued hi 8^ or 

Since situational tags allow us to relativize facts, relations between facu holding in different 
situations can be easily stated in our formalism For example, an assertion that the length 
of quetm-1 in S post is greater than the length of «UMie-i in S pre is suted as: 

{(length quaue-1) in S^) > {{length quaua-1) im S pr? ) 

This kind of assertion is quite useful to show the termination of programs. Furthermore a 
question about the identity of the queues is easily stated as: 

(qu«u«-l in S po$t ) ij-eq (queue-2 in S pre ) 

Situations are frequently referred to as the time' of message arrival, namely at the 
time when an event takes place. We use the following notations to refer to such situations. 
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Sirflj <== M]), SU««v«nt» 

4.1.3 States, Identities and Conceptual Representations 

An actor may change its state from situation to situation and different actors may 
have the same state in the same situation. Thus, in developing a specification language, we 
must distinguish the state of an actor from its Identity) 

In order to describe states of actors irt our specification language, we use 
conceptual representations introduced in Chapter 2. Identities of actors are expressed by 
syntactic constructs different from conceptual representations. The most general form to 
express the fact that an <actor> has a state expressed by a feoneoptual representation in a 
<situation> is as follows. 

«actor> u-e <conc«pt(Ml-repre*enUtion» in <aituation> 

For example, suppose that the state of an impure queue-actor Q which has three elements A 
B and C is expressed by a conceptual representation: 

(iM PURE-QUEUE {A B CJ) 

Then the fact that Q has the above state in a situation S is expressed as 

(Q u-a (IMPURE-QUEUE [A B C)» in S 

It is very important that the role of conceptual representations in our specification 



1. We assume that the identity of an actor never changes. 
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tanguage is to describe only states of actors, but not to represent identities of actors. [When 
we introduced conceptual representations to give formal specifications of data structures in 
Chapter 2, the separation of states from identities was not made clear.] 

A predicate "i*-a" is used to associate the state ©f an actor with its identity. Jn 
order to differentiate identities of actors, a predicate "U-aq" and its negation form "not-eq" 
are used Since many actors may have the same state in the same situation, when the 
following assertion holds, 

W U-a UM PURE-QUEUE [* 8 CW ftr S* 
it may or may not be the case that 

When the sharing of actors is involved, the separation of states from identities in 
the formalism considerably simplifies the process of keeping track of changes in situations. 
For example, suppose that two different cell-actors G and H contain the same impure 
queue-actor Q in a situation S. This is expressed as: 

(G U-a {CELL (com emit: Q))\ 
(H U-a {CELL {content*: Q)» 
(Q U-a {IMPURE-QUEUE (A B C])) 

Then in the situation S, an actor D is enqueued at the rear of Q. A description of the next 
situation S' can be obtained s«nply by changing the state of Q into 

(Q U-a U U PURE-QUEUE [I B C Dl» 
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and the assertions about G and H need not be modified. 1 This is an example of our 
technique of manipulating assertions which will be discussed extensively in the next 
chapter. 



4.2 Types, Views and Conceptual Representations 

Before going into the details of our specification language, it would be interesting 
to consider the roles of conceptual representations in the aaor model dt computation. 

Actors are the only objects in the model of computation. Actors are untyped. We 
do not assume that actors are intrinsically classified into subcategories such as types and 
modes. There are two reasons for this. One is that actors are objects in an abstract model 
of computation, not objects in programming languages which often have types and modes 
for reasons of reliability and implementation efficiency. Another reason, which is more 
fundamental, is that we like to emphasize the behavioral view of actors. That is to say, we 
like to be able to use two actors interchangeably and indistinguishably as long as they show 
the same behavior with respect to some purposes and environments where they are 
primarily used. Also the same actor should be able to behave qirite differently for different 
purposes and in different environments, tn other words, w* should be able to take a 
multiple view for individual actors. We believe that such multiple views encourage one to 
employ flexible disttibutien of computing power and tnteHigence such as polymorphic 
ope ratorstGreif -Hew j tt75] and the negotiation style of programming using coroutines in 
writing programs for distributed systemsftonezawa-HewittTT} end Artificial Intelligence 



1. To insure the validity of these assertions in S f , we need certain rules which will be 
discussed in Section 5.1.3, Chapter 5. 
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research[Hewitt75]. Thus it seems beneficial to allow a single actor to have a broad role 
which would be harrowed by imposing a strict type on it. 

Conceptual representations provide us with the means to express not only states of 
actors, but also multiple views and summaries of behaviors Such views and summaries 
expressed by conceptual representations facilitate the understanding and implementation of 
the behavior of actors. 



4.3 A Specification Language 

In this section, we explain basic constructs of our specification language for serial 
computations and also discuss some issues of the time variant behavior of actors related to 
specification languages. The specification language presented in this section will be 
extended to include parallel computations in Chapter 6. 

4.3.1 Specif ications of Events 

A "specification" of an event is a formal description of <f feet* caused by an event 
which takes place in an actor system. Roughly speaking, the effects of an event E are 
described by the next event caused by E and assertions which hold in the situation where 
the next event takes place The choice of the next event from the set of the subsequent 
events caused by E is determined by the level of detail and the p urp —e of the specif ication. 

A general form of specif kauon for an event in our specif ication language is 
written in the following notations: 
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<event: £ 



(Caue-4: 

<pre-cond: „ assertion* ~ > 
<cauted-event: E* > 

<po$t-cond: ... assertions _. » 



E is the event whose effects are described. Since the effect* of E may vary depending 
upon the situation where E takes plate, the description of the effect may be divided into 
more than one case. The assertions in the <pr*-cond:J> clause state the prerequisite which 
has to be satisfied in the situation where E takes place When the prerequisite is satisfied, 
the event E* in the <eauud-evemu„y clause always takes place and the assertions in the 
<po*t-cond: ..> clause hold in the situation where E' takes place. More formally, 

for E, 

if <assertions-in-pr«cond> in Sit(E) 
then 3 E' 

such that E --> E' and <«ss«rtiom-in-poskond> in SjUiE') 

The prerequisite stated in each {Ca$c-i:...) clause must be mutually exclusive. From this, the 
above notation can always specify the effects of an event deterministically. The (.event: ...> 
clause need not contain alt possible cases where E might take place. [In other words, the 
logical union of the prerequisites for each case need not be universally true} When E does 
not takes place in any of the stated cases, we assume that the caused effects are undefined. 
The scope of names and variables in the above notation is always local to each iCate-i:..) 
clause. That is, the same names and variables in different (Ca«e-fc ...) clauses do not have 
to refer to the same object. Names and variables appearing in the expression which 
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represents the event E are global to each (Cate-k~) clause 

Though the above notation is broadly applicable, we often use abbreviated forms 
for events which initiate nested activities (cf. Section %AX Chapter Jp. Suppose that the 
event E is of the form: ' "■"""*% 

[T <«■ [r»*»««t: M nply-to: Cfl 

and the corresponding caused event E' is of the form: 

[C <- [rap*,: RQ 

where R is the actor which is received by the continuation actor C in the message of E. 
Then we may use the following abbreviated form: 

<*vemt: [TC»M] 



(Co*«-t: 

<pre-c»nd: _ anertiem -> 
<rentrn: R > 



For example, the effect* of an event whefe a ceH-artor C which has the contents & receives 
the retrieving message (tomenf:) is written using the abbreviated form as follow. [Note that 
there is only one case to be specified in this example. So the (Cm.-**-) notation can be 
omitted. 3 : ■*■■:.:,:* -->--.; -'■- : > 
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<event: |[C <= [contents:)^ 

<pre-cond: (C it-a (CELL {conlentr. B)» > 

(.return: B > 

<po*r-con«S: (C is-s (CELL (contend: B)))» 

Other abbreviated forms are obtained by omitting <pre-cond:..>, <cauted-event:...>, 
<rcturn-....> or <post-cond:...> clauses. When an event has no prerequisite, the <pre-cond:...> 
clause may be omitted. For example, the creation of a cell-actor does not have any 
prerequisites. Its specification is written as follows: 

<event: fl" create-cell <= A J 
<rcturn: C* > 
<pott-cond: (C it-a {CELL (contents: A)))» 

where create-cell is an actor which creates a new cell-actor and A is its initial contents. 

In general, in our specification language, underlined words such as creat«-cell are 
constant symbols which always denote a fixed actor. Non-underlined words which denote 
an actor are free variables and can be used as pattern variables in the process of symbolic 
evaluation which we will discuss in the next chapter. The notation <actor>* means that an 
<actor> is newly created and is not is-eq (cf. Section 4.1.3) to other actors created before. 

When one is not interested in the assertions holding in a situation where the 
caused event takes place, the <pott-cond:...> clause may be omitted. Furthermore when one is 
not interested in the caused event, the <cautad-ewmt:..> or <retum: ...> clauses may be omitted 
too. For example, when the contents of a cell-actor is updated, what event is caused or 
whether the caused event might take place or not are sometimes not important. In such 
cases, a specification of the update event may be written as follows. 
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<«twnt: £C <a (uprfate: A)] 

<jMsi-eoit* (C *t-« fCKli. fawMMts; A))) » 



4.3.2 Specifications of Actors (Contracts) 

Every actor has its own finite fixed set of message types that it can accept. For 
example, a cell-actor accepts two types of messages, (cottieRi*:) and (update: <t»w-«l«m«nt», 
and a queue-actor accepts two types of messages, (119: <ne wlam e n t» and Hq:). A 
specification of an actor A must contain the specif ieatjom Of aM events, each of which is 
the receipt of one type of messages that A can accept fi should also contain the 
specification of the event where A is created, if it is possible to create A during 
computations. 

As an example, let us specify the behavior of pure queue-actor (cf. Section 3.2.2, 
Chapter 3) in our specification language. Tint, we describe the creation of a pure 
queue-actor. 

<wmr f cre« ta-pw xami e <■» fll 
irtturm Qf > 
<poMt-coni: {Q U-a {PURE-QUKUE [])) » 

This tells us the following three things: 

1) A new pure queue-actor Q is created by an event where the craato-puro-quaua actor 
receives an empty sequence actor [J. 

2) The creation event has no prerequisite. 

3) States of a pure queue-actor is expressed by conceptual representations of the form: 
{PURK-QUEUK[JD in the specification. 
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Next, we specify the enqueue event where a pure queue-actor receives (n«: <el«ment». 

<ewnt: £Q <= (119: A)J 

<pre-co»d: If) it-a (PURE-QUEUE [l*])) > 

<return: QQ* > 

<poMt-cond: 

(QQ u-a {PURE-QUEUE [Ix A])) 

(Q u-o {PURE-QUEUE [Ix])) » 

This tells us that: 

1) A new pure queue-actor QQ is created and returned, 

2) A becomes the last element of QQ and the rest of QQ's elements are the same as those 
of Q, and 

3) The state of Q does not change. 

The specification of the dequeue evenj can be written in a similar way. 

In addition to specifications of events associated with an actor A being specified, 
the specification of A may include some related information which is necessary or helpful 
for using and understanding the specification. Definitions of auxiliary conceptual 
representations used in the specification, definitions of attributes or properties of A and 
certain rules 1 concerning the validity of assertions used in the specification are examples of 
such information contained in the specification. In the case of a pure queue-actor, for 
example, the following definition of a property "length" may be given in the specification. 

Kproperty: Icngth-oftQ) s tongthfjx] 

when {Q ii-a (PURE-QUEUE [h])) > 

langih-of is the newly defined property of a pure queue-actor and length is a function 



1. Such rules will be explained in the next chapter. 
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predefined on conceptual sequences. This definition says that length-of of a pure 
queue-actor in a situation where its state* is expressed is(Qu-t {PURE-QUEUE [!x]» is 
obtained by calculating kntthf.!*]. 

We often use the term ? cbhtract* instead of "spedf teation* to emphasize the fact 
that it is an agreement or a "treaty" between the implements^ of abactor (module) and its 
designers or clients, and also between iU implemehtor and its wen. Users of a module M 
should rely only on properties stated in the contract of M. On the other hand, when 
implementors construct the module M, they are required to satisfy only what is stated in the 
contract of M. In the process of symbolic evaluation of a program which uses a module N, 
only properties of N which are derived from the contract of N should be used. In Figure 
4.2. we give a contract of pure queue-actors. It should be noted that the scope of names 
and variables in contracts are always local to specifications of events, definitions, and rules. 
For example, Q in the first <et*M:_.> clause in Figure 4.2 does not necessarily denote the 
same actor as Q in the second <ev*nt:.J> clause. 



4.S.S Validity of A«»ertkms in Specifications 

There are two important assumptions about assertion in specifications of events. 
One assumption is that states of actors which are not explicitly stated in specifications are 
unknown. That is, we assume that we do not know how an event E effects actors which are 
not mentioned in the specification of theewiot E. Tfejs assumption requires that effects of 
an event should be stated in specifications as explicitly it possible in accordance with the 
level of detail of the specifications. The crther assumption > that assertions are usually 
valid only in the situations where they are stated. If the state of an actor A is given in a 
<pre-co„d:...> clause of the specification of an event E and the state of A ts not given in the 
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Fig. 4.2. A Contract for Pure Queues 



<cvcnl: IT cr— U-purt-wu* «* f JJ 
<return: Q*) 
<pou-cond: (Q ia-a {PURE-QUEUE [])) > > 

<event: £Q <= (n?.- A)] 

<pre-cond: (Q i«-* (PURE-QUEUE [!xj» > 

<reti«-n: QQ* > 

<po»t-cond: 

V&U** iPURE*QUEUE fix A])) 

<«««nt: [Q <* (dq:jj 
(c<t»c-i: 

<pre-conrf: (Q it-a {PURE-QUEUE [))) > 

<relarn: {c*hau$te4:) > 

<P©«-c©itrf: (Q fc-« {PURE-QUEUE Hfc >■ J- 

(ease-2: 
<pr«-cond: (Q i*-« {PURE-QUEUE {B JyJ» > 
<rclur«: («T<;«/n«ueJ: BB (rmcQQ*)) > 
<po*t-coni: 

(QQ u-« {PURMWUEWltoW 

(Q fc-« (PURE-QUEUE [B !yj» > )> 

(property. lcngth-of(Q) s l«ngth[|x] 

t»A«r« (Q b-a (J>(/Kfi-(N/£(/E [|x])} > 



-74- 
corresponding <po»t-eond:.j> clause, we assume that the sta^ s p/ A after the event E is 

:■-■■■■ ^ 4 1 * '" 

unknown. It may or may not remain unchanged. For example, the state of a pure 
queue-actor after the enqueue event does hot change. A* Stated ftv the contract of pure 
queue-actors in Figure 4.2, the assertion about the state of $. p^re queue-actor: 

(Q U-m {PURE-QUEUE IU))) 



is repeated in the <po»t-cond:„> clause. Since a pure queue-actor does not change its state 
after the creation [from the definition of "purity"! this repetition of the assertion may be 
superfluous. But there is no way of knowing whether dr not the actor being specified is 
pure. ;;!..?.: ■'■ U ; ■'--• 



4.4 Examples of Specification* 

In this section, several other characteristic examples at specif ications (contracts) 
written in our specification language are given. Some of the specif ications given here are 
followed by the corresponding PLASMA i 



4.4.1 A Contract for Impure Queues 

In contrast to the contract for pure queue-actors in Figure 4.2, we give a contract 
for impure queue-actors in Figure 43. As discussed hi Section 122, an impure queue-actor 
never creates a new queue-actor in response to (««:-.) or uM messages: Instead it changes its 
own state. 



-75- 
Fig. 4.3. A Contract for Impure Queues 

<evcnt: [[creata-impura-queuc <= []] 
(return: Q* > 
<po»t-condition$: (Q it-a (IMPURE-QUEUE [])) > > 

<cvent: [Q <= {nq: A>3 

(pre-conditionr. (Q it-a {IMPURE-QUEUE [!x]» > 

(return: Q > 

<pou-condition*i (Q u-o {IMPURE-QUEUE [|x A])) > > 

<ct>cm: [Q <= {iq:)J 
{case- 1: 
Kpre-conditions: (Q ii-o {IMPURE-QUEUE [])) > 
<re(urn: (exfcanstcd:) > 
<pott-conditiont: (Q f*-o {IMPURE-QUEUE [])) > ) 

(ease-,2: 
<pre-cond«ion*: (Q it-a {IMPURE-QUEUE [B !y])) > 
(return: {dequeued: B (rati: Q)) > 
<pott-conditiont: (Q u-« {IMPURE-QUEUE [!y])) > )> 



4.4.2 A Specification for a Message-Change Interaction 

As an example of specifications for the Message-Change Type interaction (cf. 
Section 3.2.4, Chapter 3), a contract for an actor which empties the elements of one impure 
queue-actor into another impure queue-actor is given in Figure 4.4. A PLASMA 
implementation of an actor which satisfies the contract above is given in Figure 4.5. This 
implementation will be verified against the above contract by the technique of symbolic 
evaluation in Chapter 5. 
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Fig. 4.4. A Contract for •mpty-on«-qu«u«-int©-«noth«r 

<event: f •mpty-ow-quw-iwte-anothf <■ [Ql Q2fl 
<pre-eend: 

Wi$-aUUPURK-QUZVB[lxl])) 

mi*-aUMPURB-QUW*ll*2W 

(Ql net-ea Q2) > 
iretmm: {dene: [Ql Q2P > 
<l»Mt-ceii4: 

(Ql fc-o (JJf PVRE-OUEVE [))) 



■*T ! 



Fig. 4.5. A PLASMA of 

(•mpty-ono-quouo-into-MOtlNM' s 
(s> [xql sq2] itw impart fHMi ffi w w iw rf *y oijipty-om-qMOU^-into-inothor 

,-*n4 fcg w w rf «• ql •»* q2. 
#k* 4*V * mim0 metm ge U ee m to ql. 
;j/ ql b empty, the eompieint menage u received 
;th»n emptied ql «ntf extended q2 «r» returned. 
;</ql fejwf emptj^ the from element of ql and 
;the remaining e*eme ere received 
;end hound' to front-of-ql «n4 doquouod-ql. 
,lr ta t' «i q l*i ■■ « >—« < «t rear »/ q2. 
(•mpty-ono-quotM-into-anottMN' <» [doqiwiMd-ql q2])) ) )) 

jdoquoiMd-ql surf q2 ww mm to •mptyono-quMM-iiito-Miothor. 



(rulos (ql<. W 9 :>) 
(=> {rxhau*ted:) 

{done: [ql q2j)) 
(*> (<£««7u<fu0rf: «lroot-of-ql 
(re*i: sdoquouod-ql)) 

(q2 <= (fife front-of-ql)) 
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4.4.3 A Specification for a Target-Message-Change Interaction 

As an example of specifications for the Target-Message-Change Type interaction 
(cf. Section 3.2.4, Chapter 3), we give a specification for an interaction between a vender 
who sells some goods and a customer who buys the goods. The state of a vender who has 
some amount of money and goods with him is expressed by conceptual representations of 
the form 

{VENDER (bill*: [...}){goodt: {...})) 

The state of a customer who is carrying some amount of money and belongings is expressed 
by conceptual representations of the form 

{CUSTOMER {bills: {...}){belongingt: {...})) 

Their interaction is described by the event specification in Figure 4.6. 



Fig. 4.6. A Specification for an Interaction Between a Vender and a Customer 

<cvcnt: [[V <= C]j 

<pre-cond: 

(V is-a {VENDER {billt: {!bs}) {goodt: {!g !*}))) 

(C it-a {CUSTOMER {billt: {!bc !m}) {belonging*: {!p})))> 

Krelurn: C > 

<post-cond: 

(V ii-a {VENDER {billt: {!bc !m}) {goodt: Hi)))) 

(C it-a {CUSTOMER {billt: (!bcj) {belonging* {|p !«}))) 

(worthtU] = total-amount[!m]) » 
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4.4.4 Contracts for Generators 

A generator is an actor which behaves like a sequence of the possible answers to 
some problem. When it receives a (nest:) message, a next answer is generated. As 
examples, we consider two actors which successively generate increasing squares. One is a 
pure generator-actor, called a "port-df-squares* and the other is an impure one, called a 
"stream of squares". A contract for each generator is given in Figure 4.7 and Figure 4.8. In 
the first event specifications in both contracts, I and u denote the lower bound and the 
upper bound, respectively. 



Fig. 4.7. A Contract for Port-of-Square* 

<*vent: r cf«l«-porl-of-squwt <■ [| B T1 
<pre-cond: (I j u) > 
<r«!H*rn: PS* > 
<pott-cofxd: (PS Im-u (PORT-OF -SQUARES (W I) Udgk u») » 

<etwnt: [PS <= (itexl:)] 
(Co *«•-/: 
<prcrond: (PS i»~» (PORT-OF-SQUARKS (im k)(Mffc k») > 
<r«t*rm Uxhmmtedz) > 
<po»t-eond: (PS fc-a (PORT-OF-SQUARES Q—s k) {high: *))) » 

<pr*-con4: 

(PS U-a (PORT-OF-SQUARES ifo* I) (M,fc a))) 

(I < o) > 
<rcturn: [I 2 PSS*] > 
<poMt-cond; 

(PSS hm IPORT-OF-SQVARES (/ml + l){Hgku))) 
(PS i** {PQRT-OF-SQVARES (few » {Mjfc «ft» ) > 
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Fig. 4.8. A Contract for Stream-of-Squares 

<cvr.m: |f cr«at»-ttr«am-Of-8qu»f« <= ft mTI 
<prc-cond: (I <[ u) > 
<rclurn: SS* > 
</WMtrcon* (SS i«^o {STREAM-OF-SQU/iRES {low: I) (Mffc u)» » 

<c««ni: |[SS <= (next.) J 
(Ca*c- J: 
<pr<j-cort<*: (SS ii-o (STREAM-OF-$QUARBS {lorn K) (M,fc K))) > 
<rciurn: (c*haa«t«4:) > 
<po«-conrf: (SS w-« ASTREAM-0F-8QUARBS (fab; K) (Mffc k))) » 

(Cas«-2; 
<prc-conrf: 

(SS u-o iSTRB/IM-OF-SQUARES (few: I) (At* A; u))) 

(I < u) > 
<r0tarn: [I 2 SS] > 
<po»l-cond: 

(SS w-a {STRE/IM-OF-SQUARBS (fan: I ♦ 1) (M*fc u)» » > 
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4.4.5 A Contract for av«r«t* 

In this subsection, we give a contract for acton whose behavior depends directly on 
the history of incoming messages. Obviously such actors are impure. An example given 
here is a contract for the "average" actor, whiphtfetiflms the avenge of all the numbers 
which have been sent to it. The contract is given in Figure 4.9. 

The conceptual representation (AVERAGE [...]) for the actor explicitly represents 
the history (sequence) of aff the numbers which have been received by the actor. This idea 
is similar to that of Clmt0973] woo his introdmeda "raythic^ pushdown stack" to have the 
history recorded as a kind of comments in program texts to aid the verification of 
programs. The function average-of in the contract in Figure 4.9 ts defined oh conceptual 
sequences. 



Fig. 4.9. A Contract for average 

<etM>nt: f cfte-avrw <c fl 

<rt!turn: A > 

<pott-cond: (A is-a (AVERAGE [I]))) » 

<rvnm: [A <* (new-element: N)J 

<pr«-eonii (A i*-a (AVERAGE [!x])) > 

<rrlurn: A > 

<pott-c.on4: (A u-« (AVERAGE [|x N])) » 

<event: £A <= (average:)"! 

<prr-cond: (A U-a (AVERAGE (|xj» > 

<rttturn: average-offjx] > 

<poti-cond: (A i$-a (AVERAGE [tx])) » 
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4.5 Relationship to Other Work 

At this point in our exposition, it would be useful to discuss our specification 
techniques for serial computation in relation to other work in this area. 

4.5.1 Behavioral Specifications 

Based on the actor model of computation, I. Greif and C. Hewitt [Greif-Hewitt75, 
Greif75] have developed the behavioral approach to the specification technique. In their 
approach, the behavior of an actor (or an actor system) is specified in the form of axiom 
about events and the precedes order relation. Axioms describe the kinds of events that can 
or must take place and the order in which these events can or must occur. Axioms describe 
conditions which must be satisfied by computations. 

This approach can deal with the time variant behavior of actors and parallelism, 
but makes no use of the notion of states of an actor A [which we have defined as 
equivalence classes of messages sent to Al Therefore, for example, in writing axioms which 
specify responses to a message sent to A, the previous history of computations of A must be 
written out explicitly. The lack of the notion of states in their approach makes 
specifications long and difficult to understand. In particular, axioms for the behavior of 
impure actors which behave like data structures tend to be very complicated and unnatural. 
[Imagine the axioms for impure queue-actors.] The reader of such specifications of a data 
structure could understand only through reinterpreting axioms in terms of his intuitive 
notion of states of the data structure. In our approach, states of actors play the central roles 
in specifications and they are described by conceptual representations concisely, clearly and 
yet rigorously. 
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4.5.2 Burstalfs Work 

By extending Floyd-HoaretFtoyd67. Hoare69] approach, R. Burstall[l972] has 
proposed some specification and verification techniques which are able to deal with list 
processing languages with "side-effect" primitives such as rplaca and rptacd. To cope with 
the problem of side-effects in list structures, he uses a special notation for linear list 
structures. For example, a list structure 



x y 

I \ 

I I 

1 — >rm — *-* b i » > i c r^» 



is expressed in his notation as follows. 

(x -•-> y - b - e -> mil) 

Though one might find some similarity between Burstalfs notations and those based upon 
conceptual representations, it is difficult to accommodate his notations to a wide variety of 
data structures. 



4.5.3 Rich and Shrobe's Work 

C. Rich and H. Shrobe have developed a specification language for LISP which is 

i . .._> ■-.._..- 

used in their LISP understanding system[Rich-Shrobe76l In their system, the reasoning 
techniques used to deal with the problem of side-effects in LISP are along the same lines as 
ours. However, the clear separation of identities of objects from states of objects (cf. 
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Section 4.1.3) is not realized in their formalism. Thus specifications in their language tend 
to be long and are difficult to use for other programming languages. For example, let us 
look at an example of specification given in [Rich-Shrobe76l 

(Spec-fot: SWAP 

(Input: PAIR-1) 
(Output: PAIR-2) 
(Assert: 

(ID PAIR-1 PAIR-2) 

(LEFT PAIR-2 {RtCItT PAIR-1]) 

(RIGHT PAIR-1 {LEFT PAIR-1]))) 

SWAP operates on a LISP pair to exchange its left element and right element No new pairs 
are created by this operation. In the specification above, names PAIR-1 and PAIR-2 denote 
the same pair object P, which is stated by the fir* assertion in the (Assert-..) clause. The 
reason why they need to use two different names for the one object P is to distinguish the 
state of P before the operation from that of P after the operation. In our specification 
language the SWAP operation can be written without introducing a different name for P. 
Using a conceptual representation which describes the state of a pair object, a specification 
for SWAP is given as follows. 



<cvcnt: IT SWAP <= Pf 

<prc-cond: (P it-a (PAIR (left: A) (right; B))) > 
<po«-cond: (P m-« (PAIR (left: B) (right: A))) » 
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4.5.4 Floyd-Hoare Approach 

The traditional Floyd-Hoare approach[Floyd67. Hoare89, Hoare72, Igarashi-et-affc. 
Suzuki75] to the specification and verification of program* has been limited in its ability to 
deal with programs which change their behavior. For example, the sharing of data 
structures in simple ALGOL-like languages is difficult to treat* Suppose that in the 
following code x and y are two- and one-dimensional arrays, respectively. 

y<-x£3,]$ m gfiet of x U MharH by y. 

*P.4J •■«[&, 41* t|.. 

Their assignment rule cannot derive the correct value of yf4] after the above code is 
executed. The reason is that the value <te state) 1 of an program variable is not 
distinguished from its identity. 

Furthermore, the lack of the separation oT states from identities makes it difficult 
for their approach to deal with specification and verification of programs written in 
SIMULA-hke object-oriented languages. For example, their formalism is inadequate to 
deal with the following simple piece of SIMULA code 

queue- 1 t - new crette-tmpure-queueO; 
queue-2 t - qu«iM-l.«nquetw(2); 
queue-2.enqueue(3H- 

In the next chapter we will demonstrate how this kind of code is treated in our formalism. 



1. In the traditional Floyd-Hoare approach, variables in assertions denote literal program 
variables. Thus the value of a program variable should be considered as its state. 
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4.5.5 Algebraic Specification Techniques 

As discussed in Section 2.4.1, Chapter 2, algebraic techniques [Zilles74, Guttag75] 
have been developed for the specification of abstract data types{Liskov-Zilles74]. In the 
algebraic approach, all operations and procedures are specified u* functions, which leads to 
a serious problem; the purity and impurity (cf. Section 3.2.1, Chapter 3) of data structures 
cannot be easily distinguished. 

As an example, let us consider an algebraic specification of queues given in 
[Guttag75]. Important operations on a queue are ADO and REMOVE, whose functionality is 
as follows. 

ADO : Queue x Integer — > Queue 
REMOVE : Queue — > Queue 

The essential part of the specification is given by the following equation: 

REMOVE(ADD(q, i)) = ADD(REMOVE(q), i) (*) 

where q is not an empty queue. In their interpretation, operations such as ADD and REMOVE 
always create new objects and cause no side-effects to the objects that they operate on. 
Equations of operations such as («) define congruence relations over the word algebra 
constructed from the operations and objects. Thus in their approach, algebraic techniques 
are used to specify the behavior of only pure actors (immutable objects). 

There is another interpretation. If we consider the domain and range of 
operations as sets of states of objects, equations (axioms) of the operations can define 
congruence relations over the states of objects. In this interpretation, algebraic techniques 
can be used only for impure actors (mutable objects) 
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In either interpretation, the algebraic approach has difficulties in dealing with 
both pure actors and impure actors simultaneously. Techniques developed by J. Spitzen 
and B. Wegbreit [Spiuen-Wegbr«t75, Wegbre*t-$piUen76} hive the ume problem of 
distinguishing the purity and impurity of data structures. 
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5. Verifying Serial Computations 



In this chapter, our verification techniques for serial computations are presented. 
The first section describes the method of symbolic evaluation which Is the major 
instrument in our verification techniques. It also contains a detailed explanation of our 
reasoning method which can be employed in environments where computations may cause 
side-effects. The next two sections describe our verification methods, each of which is 
applied to different types of actors. Then; to close the chapter, we reflect on our method of 
symbolic evaluation and discuss its application to other areas. 
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5. 1 Symbolic Evaluation 

In this section, we will describe our basic method of symbolic evaluation, the major 
instrument of our verification techniques. A simple example of symbolic evaluation of 
PLASMA code which involves sharing of actors with side-effects is given at the end of the 
section. Although in this thesis we consider symbolic evaluation primarily as a tool for 
program verification, it is also useful for other purposes such as program testing, 
debugging, optimization, dependency analysis, perturbation analysis etc The chapter 
concludes with a discussion of some potential applications. 



5.1.1 Overview 

Symbolic evaluation is a process which abstractly [symbolically] executes programs 
on abstract [symbolic, as opposed to "concreteT data. When a program takes numerical 
input, the symbolic evaluation of the program does not deal with concrete numbers such as 
123. 1776. and 1984, but rather with symbolically expressed numbers such as "nl", "n2", and 

N M 

m . 

Though symbolic evaluation is an extension of ordinary execution of programs, it 
differs from ordinary execution in the following points. 

(1) The only properties of input that can be used are the ones specif iced as the 
prerequisites of a moduk being symbolically evaluated. [E^ input numbers are 
required to be positive integers.] 

(2) When the symbolic evaluation of a module M encounters an invocation of some 
module N. the specification fcontractj of ;.N U wed to continue the symbolic 
evaluation. The implementation of N is not used. 
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Symbolie evaluation can be viewed as a mechanization of the process of a human 
programmer tracing a program without using concrete values to understand the 
computations expressed by the program. 

In symbolic evaluation, the code of a module is interpreted step by step according 
to either pre-defined semantics of language primitives or specifications of modules invoked 
in the module. Each such step is triggered by the symbolic evaluation of an expression in 
the code which corresponds to an event [cf. Section 3.1.2, Chapter 3]. The state of the 
program [code] at each moment before and after an interpretation step is referred to as a 
situation. The symbolic evaluator 1 has a data base to record what events occur, what facts 
hold and what is assumed in each situation. Facts that hold in a situation S are recorded 
as assertions associated with S. 

Since each expression is interpreted on abstract data, when a conditional expression 
is interpreted, the subsequent symbolic execution path must split in the usual , 
f ashion[Deutch 1973]. For example, consider the symbolic evaluation of 

if (P x) then ... cite .... 

After the symbolic evaluation of the expression (P x), the symbolic execution path splits into 
two branches: one for the then-clause and the other for the else-clause. To start the 
subsequent symbolic evaluation, (P x) must be assumed for the then-clause and -.(P x) for 
the else-clause. If the evaluation of (P x) has no side-effects, the assertions holding in the 
situation where (P x) is evaluated are inherited for both clauses. 

In essence, symbolic evaluation is a process which abstractly evaluates the code 



1. In this chapter, we assume that symbolic evaluation is carried out by a hypothetical 

system. 
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Fig. 5.1. A Situational Tree 




forward along the execution path and produces a tree structure whose nodes correspond to 
situations. At each node of the tree, assertions which hold in the corresponding situations 
are entered. We call this structure a situational tru. {See Figure 5.1.] The assertions 
entered in the situational tree are used as the primary source of information for answering 
questions about the implementation. As we shall later see, vertficatiort of implementations is 
carried out by using such situational trees. 



5.1.2 Partial Descriptions of Situations 

In order to illustrate how assertions are handled in a situational tree, we 
symbolically evaluate the following piece of code 

-S- 

(queue-1 <* [n r . $)) ,-queue-l reenves a me stage (nq: 6) 

-S'- 

(qiwiM-1 <= (nq: 8)) ;queut-l wives a message (n 9 : 8} 
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S, S', and S" denote situations before or after the events corresponding to 
statements in the code. We assume that two distinct impure queues, queue-1 and queue-2 
have been created before the situation S and assertions about states of the two queues are 
already entered at the node for S in a situational tree. See the diagram below. 

I 

S : ( queue-1 is-a UM PURE-QUEUE [3 7 11])) 

I ( queue-2 is-a UM PURE-QUEUE [2 4])) 

I 

With these assumptions, the first statement in the code which expresses an event 
[[queue-1 <= (« 7 .- 6)]| is interpreted. To know what effects are caused by this event, the 
symbolic evaluator first looks for an assertions about the state of queue-1 at the node for S 
in the situational tree. It finds that the state [or conceptual type] of queue-1 is expressed as 

UM PURE-QUEUE [3 7 11]) 

From the form of the conceptual representation [i.e., from "'IMPURE-QUEUE"), the contract 
for impure queues in Figure 5.2 is referred to. 

The event expression |[Q <= (nq: A)]| in the second <cvent:...> clause in the contract 
for impure queues in Figure 5.2 matches against the event IT queue-1 <= {nq: 6)]|. Also the 
assertion 

(Q is-a {IMPURE-QUEUE [!x]» 

in the <«iwni:...> clause matches against the assertion 

( queue-1 is-a UM PURE-QUEUE [3 7 11])) 

which has been entered at the node for S. Thus the whole second <evcnt:..> clause can be 
instantiated as follows. 
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Fig. 5.2. A Contract for Impure Queues 

<ciw»mi: f craaU-impw -queue <g [fl 
<relurn: Q* > 
<pon-c*ni: (Q »t-o UU PURE-QUEUE {])) > > 

<<>tH>nl: [Q<=(i«7:A)J 

<pr«-cond: (Q *«-« (IMPURE-QUEUE [U])) > 

<r*f urn: Q > 

<;m>ji-coii4: (Q Is-a (I M PURE-QUEUE [\t AJ)) > > 

<«twnf: [Q <*(«/<|:)] 

<pre-eond: (Q i*-« {I M PURE-QUEUE \X» > 

Krelurn: {exhausted:) > 

<no*t-c*ni: «J fe-« (/*/ PURE-QUEUE [J)) > ) 

<prc- C o«rf: (Q ij-o (/A/Pi;RE-0(yR;E [B !y])) > 

Crrturit: (rfcqcieuetf: B (r«j<: Q)) > 

<po»t-cond: (Q i*-« U M PURE-QUEUE [ly])) > )> 



<«n;rnt: B" qu«u»-1 <= Ow 6)1 

<prr-ron<f: ( quew-1 i«-« UM PURE-QUEUE f3 7 11J)» 

<r«iuf»i: queue- 1 > 

<|M><i-coR<f: ( queue-1 u-c {IMPURE-QUEUE [3 7 11 6]))» 

The symbolic evaluator enters the assertion in the above <i*mi-coi«!:...> clause at the node 
for the next situation S*. Also it records what event took place between the two situations. 
See the upper diagram in Figure 5.3. The second statement in the code expresses an event 
[queua-1 <= {nq: 8)], which is interpreted in the same way as above. The effect of this 
event is recorded at the node for the next situation 8" as shown in the lower diagram of 
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Figure 5.3. 

An important point in the manipulation of assertions described above is that the 
assertion about the other impure queue actor, queue-2, is left untouched, neither copied nor 
modified in going from S to S' and S". As the diagrams in Figures 5.3 show, the 
situational tree thus generated by the symbolic evaluation does not contain assertions about 
the states of queue-2 at the nodes for S' and S". In general, a situational tree generated 

Fig. 5.3. 

S : ( queue- 1 is-a {IMPURE-QUEUE [3 7 11])) 
| ( queue-2 is-a {IMPURE-QUEUE [2 4])) 

I 
B" queue-1 <= {nq: 6)]| 

I 
S' : ( queue-1 is-a {IMPURE-QUEUE [3 7 11 6])) 



S : ( queue-1 i»-a {IMPURE-QUEUE [3 7 11])) 
| ( queue-2 is-a {IMPURE-QUEUE [2 4])) 

I 
D" queue-1 <= {nq: 6)]| 

I 
S' : ( queue-1 is-a {IMPURE-QUEUE [3 7 11 6])) 

I 
IT queue-1 <= {nq: 8)J 

I 
S" : ( queue-1 is-a {IMPURE-QUEUE [3 7 116 8])) 
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by symbolic evaluation is only a partial description of situations. When one needs to know 
states of actors or relations holding in a situation, which are net explicitly asserted at the 
corresponding node in the situational tree, one must rely on the reasoning method described 
in the next subsection. 



5.1.3 Tlie Method of Reasoning (Uses of the Trans-situational Rules) 

In this subsection, we will illustrate how situational trees are used for the reasoning 
in our formalism. In general, questions about a given situation are answered by reasoning 
backward. That is, to answer questions such as whether some assertions hold in a situation 
S or in what states some actors are in S, a situational tree is looked at from the node for S 
to previous situations. 

For example, suppose that a situational tree shown in Figure 5.4 is given and we 
want to know the state of Q in a situation S 7 . First we try to find some assertion which 
describes the state of Q at the node for the situation S 7 . Since the given situational tree 
does not have any assertions about Q at the node for S 7 , we look for assertions about Q 
backward along the branch of the situational tree. [See the dotted line in Figure 5.4 J An 
assertion 

(Q iM-a {IMPURE-QUEUE [2 5 4])) 

is found at the node for S3. However, all we know at this point is that the assertion holds 
in S 3 . but we are not sure that the assertion holds in S 7 , because some events which 
destroy the validity of this assertion in S 7 might have occured between S3 and S 7 . So we 
must check on such events. 

In order to know what events nullify the validity of assertion, each event 
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Fig. 5.4. Reasoning Backward 



I 

83: (Q U-a UU PURE-QUEUE [2 4 5])) 






S 6 S* 



specification in the contract for impure queues shown in Figure 5.2 is examined. If in the 
specification for an event £ the state of Q stated in the <pr*-cond:..> clause is different from 
the one in the corresponding <po*t-cond:..> clause, the event E nullifies the validity of the 
assertion. In fact, [Q <« M*:)J and f Q <* inyJiJ turn out to be such nullifying events. 

The process of finding the nullifying events can be saved if the contract contains 
an explicit statement which indicates such events. For this purpose, we may add the 



following clause to the contract for impure queues.' 



<for-at*crtion: (Q it-a UM PURE-QUEUE [_.])) 
<only-affccting-event*-are: 

<£ti <- fos-)]. EQ 4> (Ml) >> 

This statement says that the validity of assertions of the form 

(Q i$-a {IMPURE-QUEUE [„])) 



1. <for-a»scrtion:...> clauses do not have to be placed in contracts for actors. They can be 
placed in some global place to which the symbolic evaluator have access. 
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is destroyed only by the set of events appearing in the ^irfy-*//****^ daus* 2 
In our formalism, assertions of the forin 

««ctor> ii-a <conc«ptu*l-r«pr«*«nt«tion» 

can be inherited from an ancestor situation Sj to a descendant situation Sj if the following 
two conditions are met: 

<1) The events specified in the corresponding <for-auertion:..> clause do not take 
place between Sj and S:. 

(2) At the node for the descendant situation Sj, no assertions about the <«etor> 
have been entered which use the same form of conceptual representation as used in 
the assertion being inherited from Sj. 

By virtue of the second condition, we do not have io keep adding events to the 
<for-ass<,nion...> dause every time we implement a new actor wWcJi changes the state of the 
<«ctor>. For example, suppose that an actor •mptyiftj-qu.u* which empties the elements of 
an impure queue-actor is implemented and that iu specification is given as follows! 

<*vcnt: iT emptying-queue <= 0/f 

<pr«-«W: (Q U-a (IMPURE-QUEUE [!x]))> 
<pou-cond: (Q U-a (IMPURE-QUEUE W$& 

When the PLASMA expression (.mpiyinf-quau. <* Q) ; is syn^olicaHy interpreted in a 
situation S where (Q U-a (IM PURE-QUEUE [1 2 3])) holds, the assertion 
<Q U-a (IMPURE-QUEUE [})) is entered at the node for the next situation S' If we did not 
have the above condition (2), the assertion (Q U-a (IMPURE-QUEUE [I 2 3])) could be 



2. Note that this reasoning is valid only for serial computations. It is not valid if there are 
concurrent events. 
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inhetited to S'. To prevent this invalid inheritance without the condition (2). we would 
need to add the event IT emptying-queue <= Qj to the list of nullifying events. 

In general, the rule which indicates what conditions guarantee valid inheritances of 
assertions from one situation to another is catted a tranS'Situational rule. For particular 
assertions or particular forms of assertions, appropriate, trans-situational rules are necessary 
for correct reasoning. The <for-a»urtiom..> clauses given in contracts are one type of 
trans-situational rules. In Section 5.1.5, some examples of trans-situational rules are listed. 
The reasoning using trans-situational rules described here is a procedural a pproach to 
McCarthy's frame problem [McCarthy-Haye*69l We will discuss this issue in Section 5.4. 



5.1.4 Variables and Identifiers 

In this subsection, we will explain how names for actors are handled in symbolic 
evaluation for programs written in PLASMA. The technique given here allows us to deal 
efficiently with the problem of both identity and sharing of actors. 

Names in PLASMA fall into two classes: variables and identifiers. A variable x 
can be declared and also initialized with the value of an expression <E1> by the following 
form of statements 

(let (x initially <E1»...) 

The value of x can be changed only by executing expressions of .the. {prm- 

(x «- <E2». 

Occurrences of x in programs except in the above form stand for the value of x. A 
variable x is usually implemented by a cell actor, but in that case an expression x in code 
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does not stand for the cell actor itself, but rather for the content* of the cell actor. In 
symbolic evaluation, to state that a <v B ri«bl«> has an <actor> as its value in come situation, 
assertions of the following form are used. 

«v«ri*bl«> WvdiM <actor» 

When the symbolic evaluator interprets an expression 

(x«-<D). 

in a situation S, the following assertion 

(x fatHwnur B) 

is entered at the node for the next situation, where B is the value of <D in S. 

An identifier is declared and bound to an actor in the course of program 
execution. To express that an <id«ntifi«r> is bound to an <actor>, we use assertions of the 
form 

«id«ntifi«r> s <actor>) 

In the symbolic evaluation of a module M, an identifier x used in the code of M can be 
always regarded as the actor that it is bound to, because one identifier is not bound to more 
than one actor throughout the symbolic evaluation of M. This is guaranteed by: 

(1) the restriction on the syntax of PLASMA that no names are declared more than 
once inside a module, and 

(2) the fact that symbolic evaluation passes Over eath expression in a module 
exactly once.' 



I. This fact is true only when symbolic evaluation is used for program verification. 
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When more than one symbol [here, symbols mean ones denoting actors in contracts 
(such as Q in Figure 5.2) as well as indentifiers in programs] denotes the same actor, we use 
assertions of the form 

«symbol-l> is-eq <symbol-2» 

As an identifier can be regarded as the actor that it is bound to, the relation "h-cq" and "=" 
can be used indistinguishably. Since the relation "is-eq" is an equivalence relation, it forms 
an equivalence class of identifiers in programs and symbols denoting actors in contracts. 
Every member of such an equivalence class denotes the same actor. In symbolic evaluation, 
one identifier (or symbol) is chosen from each class [e.g., the one which is first used among 
the members of the class] and any uses or occurrences of other members in the same class 
are always considered as those of the chosen one. To record the state of an actor A, the 
symbolic evaluator always uses the one chosen identifier or symbol for A throughout all the 
situations. This arrangement eases the handling of shared actors in symbolic evaluation. 

To illustrate the use of identifiers and symbols explained above, let us consider 
the following piece of code. This code is a PLASMA version of the SIMULA code given 
in Section 4.5.4, Chapter 4 as an example which is difficult for the Floyd-Hoare technique. 

"So" 
[let (queue-1 = (create-impure-queue )) 
then - Sj - 

(/«i (queue-2 s (queue-1 <= (nq: 2))) 
then - So - 

(queue-2 <= {nq: 3)) 

-s 3 - 

S ,...,S 3 denote situations before or after the events corresponding to statements in the 
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code. In what follows, the notation 

in S^ : .„<aw«Hion>... 

means that <assertion>s are entered at the node for S _ in a situational tree. 

The event I croato-impure-queue <s Hi takes place in S . By virtue of the 
contract for impure queues in Figure 5.2, we know an empty impure queue-actor is created. 
Then the let statement binds the identifier queue-l to the empty queue-actor. We may use 
a symbol Q for the newly created actor and record this event by two assertions 

(Qis-a {I H PURE-QUEUE [])) 

but one assertion suffices. Namely, 

in8 1 : i aumvl it-a U U PURE-QUEUE [])) 

The second statement of the above PLASMA code is interpreted by using the 
following event specification instantiated from the clause in the contract for impure queues 

<«imnt: ff" quw-l <« (my; 2fl 

< P rc-cond: ( quew-1 is-a (I M PURE-QUEUE []))> 

<rciurn: qu«ue-l > 

<po*t-cand: ( queue-1 it-a (IMPURE-QUEUE [2]))» 

The state of queua-1 is changed as described by the assertion in the <pott-cond:..> clause 
and quaiw-1 is returned. The let statement tells us that the retamed qu*u»*l *s bound to 
qu*u«-2. Thus 

inS 2 i ( gu«u»-l »-a (IMPURE-QUEUE [2])) 
( queue- 1 i*-««i queue-2) 
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In interpreting the third statement, since we know that queue-2 and queue-1 denote 
the same impure actor, the event IT queue-2 <= {nq: 3)]| stands for IT queue-1 <= {nq: 3)]j. 
Thus the change in the state of queue-1 is recorded as 

in S 3 : ( queue-1 it-a {IMPURE-QUEUE [2 3])) 

Any references to queue-2 in the interpretation of the subsequent statements in the code are 
treated as the references to queue-1. 



5.1.5 Examples of Trans-Situational Rules 

In this subsection, we will give the trans-situational rules which will be used in the 
examples of symbolic evaluation in this thesis 

( :) Assertions of the form «identifier> = <»ctor» 

which state that <identifier> is bound to <actor>, can be passed unchanged between any two 

situations within the scope of <identifier>. 

(:) Assertions of the form (<actorl> it-eq <actor2» and «actorl> not-eq <actor2>), 
which state the identity of actors, can be always inherited from one situation to another 
without any conditions. 

(*) Assertions of the form 

(<c-sequencel> = <c-sequence2» and «e-sequencel> i» <c-sequence2», 
which state the equality of conceptual sequences appearing in conceptual representations, 
can also be inherited without any conditions. [Note that <CM«quenc«l> and <c-sequenc«2> 
are not sequence-actors but mathematical sequences. All mathematical facts can be 
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inherited without any conditions. This is a special case.} 

<*) Assertions of the form K«etor> tt-* (StfC^^tWJ) 

which state that <actor> is a sequence-actor whose eferftetitt are Ik, can be inherited without 

any conditions because a sequence-actor is a pure actor which never changes its state, 

<a) Assertions of the form (<vwiaW«> has-volue <actor» 

which state that <variabl«> has <actor> as its value in some situation S, can be inherited to a 

situation T if no assignments to this <variable> take place between S and T. (Cf. Section 

5.1.4.) 



5.2 Verification of Actors Behaving as Procedures 

Methods of verification reflect methods of specification. Roughly speaking, two 
methods have been employed in the specification technique presented in the previous 
chapter. 

One method is to specify the behavior of an actor A in terms of the states or the 
changes in the state of other actors which are sent to A, or which are created during the 
invocations of A. In this method, the state of A is n,ot used in specifying the behavior of 
A. Most actors which behave purely as "procedures" are specified by this method. A 
typical example of such actors is •w^iy-one-queue-inlc-another. [See Section 4.4.2, Chapter 
4.] In general, this method applies to the specifications of the aclors which are targets in 
the No-Change-Type and Message-Change-Type interactions introduced in Section 3.2.4, 
Chapter S. 

The other method is to specif y the behavior of an actor B in tirms of the changes 
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in the state of B itself. Actors which behave as "information storage", such as data 
structures and generators, are specified by this method. 

In this section, we will illustrate our verification techniques for actors behaving like 
procedures, whose behaviors are specified by the first method mentioned above. The 
verification techniques corresponding to the second specification method will be discussed 
in the next section. However, since actors are essentially procedural objects whose 
implementations are written as programs, most of the techniques that will be discussed in 
this section [such as the handling of recursion, loop, case splitting and convergence] are 
necessary bases for the verification of information-storage-like actors. 



5.2.1 Symbolic Evaluation in the Context of Specifications 

In order to verify an implementation of an actor against its specification, symbolic 
evaluation of the implementation tie. code or script] is carried out in the context of the 
specification. In our formalism, a specification of an actor which behaves like a procedure 
is expressed by a specification of the event which initiates the invocation of the actor. A 
specification consists of the preconditions for the incoming message [i.e. input], and the 
postconditions to be satisfied by the result of the invocation. Thus the symbolic evaluation 
of the implementation is started with the assumption that the preconditions are satisfied. 
Under this assumption the symbolic evaluation is carried out and then the results of the 
symbolic evaluation are examined as to whether they satisfy the postconditions given in the 
specification. 

Below we will demonstrate the verification of an implementation of 
empty-one-queue-into-another [hereafter empty] against its contract. Its contract and 
PLASMA code are given in Figure 5.5. The code is augmented with situational symbols 
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Fig. 5.5. A Contract and Implementation of owpty-ono-quouo^nto-aflothor 

<ttv<mi: T •mpiv'on»-am\)9"Mo-m^ tr<iflQl Q2fl 
<pre-cond: 

m i«-o uhpurk-qusux tmm 

(Ql noi-«v Q2) > 

<rrluriK (rfoit«: [Q1.Q2]) > 

<poat-cond: 

(Ql fa-«. VHPUREWEVBty) 

(Q2 !•-« (/If PURE-QUEUE [!»2 Ixl])) » 



(•mpty-ono-quouo-into-anothor s 
(s> [=ql =q2] .-two impart annus om racmed by orapty-ono-quouo-into-anothor 

ittnd ql awd q2 ore bound to thorn. 

rocoived-quouos 
(ruios (ql <« (4*:)} jtA* rfoawaMftf memmgo i* tent io ql. 

(s> («*fam«tft<*:) |J/ql li empty, the compleint meumge U generated 

" S«xhfuct«d-ql ' 

Won*: [ql q2}) ) {**«» emptied ql oarf extended q2 ore returned. 

(s> <m**ti =1ront*of-ql p7 i* *•« «o»p«y, front-of-ql 

(rMC sdoqiffuod-ql)) t»w»d doq vpu o o> ql 

.are 6ounrf <o lAe /roM e/eBMMt e/ ql and tfo r«ma>MRf queue, retpeetively. 

" °d«quouod-ql " 

(q2 <= (n«7.- front-of-ql)) ;front-of-ql u enqueue** at rear of q2. 

_ c 

i0 «nquou«d-q2 

(empty-ono-quouo-into-anothor <* [daquouod-ql q2]M ) 1) 

;d*quouod-ql and q2 «r» mm to ompty-ono-quouo-into-anothor. 
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which denote situations before/after events corresponding to each statement. Note that this 
implementation contains a conditional branch and a recursion, the handling of which will 
be explained below. 

First, the preconditions of empty in its contract are entered in the data base. 

in S initial : 

(Ql is-a {IMPURE-QUEUE [!xl])) 

(Q2 is-a (IMPURE-QUEUE [!x2]» 

(Ql not-aq Q2) 

After the symbolic pattern matching is performed, identifiers ql and q2 are bound to Ql 
and Q2, respectively. So this is recorded in the data base as the following assertions. 

'" ° received-queues : 

(al = QD 

tg2 = Q2) 

Then the PLASMA expression (ql <= [dq:)) in the rules-statement is interpreted. The 
dequeuing message {dq:) is sent to Ql that ql is bound to. To know the result of this 
event, the symbolic evaluator must consult the <event..> clause for the dequeuing in the 
contract: 

<<!vcnt: [Ql <= (dq:)J 
(case- 1: 

<prc-cond: (Ql is-a (IMPURE-QUEUE [])) > 

<rcturn: (exhausted:) > 

<post-cond: (Ql is-a (IMPURE-QUEUE [])) > ) 
(casc-2: 

< P re-cond: (Ql is-a (IMPURE-QUEUE [B !y])) > 

<rcturn: (next: B (rest: Ql)) > 

<post-cond: (Ql is-a (IMPURE-QUEUE [!y])) » > 
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[Note that the above clause is an instantiation of the <evetuj> clause for the dequeuing in 
the contract for impure queues in Figure 5.2. which ** obtained by substituting Ql for Qj 
Now the symbolic evaluator has to consider two cases: where Ql is empty and where Ql is 
not empty. (See the situational tree for this example in Figure 5.6.) 

Case 1: (Ql i»-a U IMPURE-QUEUE [])) 

In this case, the contract specifies that the {cxha*Mti:\ message should be returned. This 
message matches against the first (s>.„)-5tatement inside the {ruta»~) statement. To follow 
this path, xl = [] must be assumed. So at the node for S 9X hauat«d-al' tne I "°N° w ' n g 
assertions are entered. 

*" S «xhaust«d-ql : 
(xl = []) 

(Ql it-a {IMPURE-QUEUE [})) 

Then the result of the invocation, the message {done: [ql q2]), is returned in S^xhaugtod-ql* 
For this resu It, there are three postconditions stated in the contract of empty: 

Fig. 5.6. 

S initial ' 



e 

' r«c«iv*d~qu*uM 



exhauct«d-ql 




^•nquou«d-q2 
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rl: {dona: [Ql Q2J) must be returned 

r2: (Ql i*-a {IMPURE-QUEUE [))) must hold, and 

r3: (Q2 i*-a {IMPURE-QUEUE [|x2 |xl]» must hold. 

It is easy to show that each postcondition is satisfied in Saxhaugt^d-ql 1 

(*) for rl, since the trans-situational rules for binding allow the inheritance of the 

assertions (gi = Ql) and <g2 s Q2) from S r-ertw<H|OW| „ to S^,^.^, 

the required message is returned in Sixhautlad-ql' 
(*) for r2, the assertion (Ql »*-« (IMPURE-QUEUE []}) is entered at the node for 

S exhaust«d-ql 1 and 
(*) for r3, the two facts guarantee that the requirement is satisfied: 

(1) (Q2 i*-a {IMPURE-QUEUE [1x2])) can be inherited from S jnitja , to 
^•xhaust«d-ql °y usm S thc trans-situational rule for 

(Q2 i»-a {IMPURE-QUEUE [...])) [which Is obtained by instantiating the 
<for-atscriion:..> clause in the contract for impure queues. Cf. Section 5.1.3.]. 
This inheritance is legitimate because neither £Q2 <* {nq:...)J nor 
[Q2 <= {dq:)J have happended and no assertions of the form 
(Q2 is-a{I M PURE-QUEUE [...])) have been entered at the node for 

S 

°exhausted-ql' 

(2) [1x2] « [!x2 !xl] holds in S,,^^.^ because xl ■ [] holds in 
S exha»»i.d-ql- U!x2 !xi]*[!x2 ![]] - [1x2] ) 

Therefore (Q2 i»-a {IMPURE-QUEUE [!x2 |il]» holds in S #||hautt#d ^ ql , Thus Case-1 is 

verified. 
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Case-2: (Ql u-a UHPURK-QUKUB tttM)) 

In this case, the contract for impure queues tells us that (iwsri; B {rett: Ql)) is the result of 
(ql <= idq:)) where the following assertions are assumed. 

Ul = [B!y]) 

(Ql U-a (IMPURE-QUEUE [ly])) 

The result {next: B (re«: Ql)) is matched against th« pattern in the second (5>„.) statement 
inside the (rules...) statement. At the node for ^^ mmti ft *e binding information is 
also entered together with the above assumption. 



in S 



'dequeued-ql : 
( Iront-of-ql z B) 

( dequeued-ql e 01) 

(xl = [B!yJ) 

(Ql h-a UklPVRE-QUKUE [!y])) 

Then the PLASMA expression (q2 <■ (m/: front-of-ql)) is interpreted in this situation. 
Since q2 is bound to Q, and front-of-ql is bound to B [from the trans-situational rule for the 
binding], the event taking place is £Q2 <■ (n«: B)J. Tp*now the effects of this event, the 
system refers to the second <event:..> clause in the contract for impure queues in Figure 5.2- 
The state of Q2 in Sdequeue-ql is obtained, from the assertion 
(Q2 iVo (/A/P^KB-at/K(/K [!x2])) at the node for f^^ Because it can be inherited to 
^d*qu«u«d-ql for tne same reason as explained above in the case of its inheritance from 
S inHi«l to S d«qu«u«d-ql Thus * e second <e**nt:J> clause is instantiated as follows. [Note 
the substitutions of Q2 for Q, x2 for x and B for A.] 
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<cvcnt: |[Q2 <= (nq: B)]| 

<prc-cond: (Q2 u-e (IMPURE-QUEUE [1x2])) > 

<rcturn: Q2> 

<poH-cond: (Q2 it-a {IMPURE-QUEUE [!x2 B])) » 

The assertion in the <po»t-cond:...> clause is entered at the node for S -nqu#u#d ^ 2 - 

in S enqueued-q2 : W 2 *•"• (IMPURE-QUEUE [!x2 B])) 

Now the last PLASMA statement (empty <= [dequeue-ql q 2]) is interpreted. From the 
binding information, the corresponding event is IT empty <= [Ql Q2]]j. To know the effects 
of this event, the contract for empty in Figure 5.5 is referred to. Since we are trying to 
verify the code against this contract, this is a "recursive" 1 use of the contract. The 
preconditions stated in this contract must be satisfied before it can be used. In fact, the 
assertions: 

(Ql iVo (IMPURE-QUEUE [fy]» and (Ql not-eq Q2) 
can be inherited from S dequ#U0d _ ql by the trans-situational rules for 

(Ql ix-a (IMPURE-QUEUE [...])) and «actorl> not- eq <«etor2», 
respectively. Thus the following assertions hold in S -nqu# 2 

(Ql i*-a (IMPURE-QUEUE [!y]» 
(Q2 »*-o (IMPURE-QUEUE [!x2 B)]) 
(Ql not-eq Q2) 

Therefore the preconditions of empty are satisfied. Now the postconditions of the contract 
for empty guarantee that (done: [Ql Q2]) is returned and that the following assertions: 



I. Recursion and iteration in symbolic evaluation are discussed in Appendix HI. 
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(01 i*-a UUPURK-QUEUB [J)) and 

<Q2 «Vo UMPUKWUKUK [111x2 B] |y))) hold. 

hold in the situation following 8 #| ^^^ Facts about c-sequence* 

[![«x2 B] !y] - [!x2 B lyj, 

[!x2 B !y] « [1x2 |xl), if xl * [B lyj. 

are used to simplify the above assertions. That is, since xl « [B |y] can be inherited from 

&doquei»cH|l b y the trans-tituational rule for « c- Mq u e n cel> ■ <c-««qu«f««2», it follows 
that 

(Ql h-o VHP URE-QUBUg Q» 

<Q2 fa-« (I H PURE-QUEUE [1x2 1x1])). 

Thus the post-conditions for «mpty-on«-qu«u«-»nto-«noth«r are also satisfied in Case-2. 

Though it has been shown that both Case-1 and Case-2 meet the postconditions for 
•mpty, we cannot conclude that the implementation of empty in Figure 53 satisfies its 
contract, because the convergence of the invocation of the implementation is not 
guaranteed, although it is, expfidtly required by the contract Stecatl the meaning of 
<return:...> clauses given in the previous chapterj For after splitting into two cases at the 
(rule*...) statement, the symbolic evaluation for both Case-l and Case-2 is resumed under the 
assumption that the control has reached the points corresponding to S #JthaUf|-d _^ and 
®d«qu«iMd-ql- Therefore, to demonstrate that the above assumption is always guaranteed 
is another part of the verification process. This issue to discussed in Appendix IV. 
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5.3 Verification of Actors Behaving as Information Storage 

In this section, we will present our specification techniques for actors whose 
behaviors are specified in terms of their own states [or changes in their own states]. 
Specifications of actors which behave as "information storage" such as data structures and 
generators [Section 4.4.4] are often written in terms of their own states. For the verification 
of implementations of these actors, symbolic evaluation is still the major instrument and all 
the techniques presented in the previous section are still employed. In addition, however, 
special considerations are necessary in dealing with conceptual *epresentations of the actors 
being virif ied. We will discuss such considerations in the next subsection. 



5.3.1 Implementation Invariants 

The specification of impure queue actors in Figure 5.2 is written in terms of the 
changes in their states before and after their invocations, and their states are expressed by 
conceptual representations of the following form. 

{IMPURE-QUEUE [...]) 

When some program which contains invocations of impure queue actors is symbolically 
evaluated, conceptual representations of the above form are used only to record states of the 
impure queue actors. One need not pay attention to what those conceptual representations 
really stand for, as long as they represent the states of the impure queue actors at the 
conceptual level. However, when an implementation [script or code] of an impure queue 
actor Q itself is verified against its specification, what the conceptual representation 
expresses in terms of the implementation, or more precisely, how the state of Q expressed by 
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the conceptual representation corresponds to the states of the constituents of Us 
implementation, must be considered. 

Suppose thai the PLASMA implementation of an impure queue actor given in 
Figure 5.7 is to be verified against the contract in Figure 32. In this implementation, the 
elements of the queue are kept as the elements of a sequence actor that is the value of the 
variable queuees. This could be expressed by tfcj* diagram in Figure SS, where bakes 
represent actors and arrows express the know-about relations. This diagram is only a 
partial and static description of the impteroentation, yet it illustrates an invariant or 

Fig. 5.1. A PLASMA Implementation of an Impure Queue Actor 



(create-impure-queue s 
(=> [] 
(/rt (qtwtmes initially []) 

th«n 

(the~queue-itself s 

(cases 
(«> inq: =n«w-element) 



;create-imp u re -queu e receives an empty sequence. 

u variable queueee U declared 

;and imt i oliood wUh mm empty mtmuence. 

\a queue-actor denoted my the-queue-itseif is defined 

i by the cmmm^statement given below. 



\when an enqueue messag e with an element is received, 
pww^momumt it bound to the element. 
(queuees «- [fqueuees new-element]) ,o new sequenco-mctor whose elements are 

Vke unpack of the value of queueee and new-element 

rfj created and stored in queueee. 

the~queue-ttse4f) :^tium thi-queue-fbeM i, r.iurn^. 

(s><«V> 
(fuiee quaueee 
(s> [] (exhausted:) ) 
(a> [sfront !>rest] 

pre bound to Us first 
(queuees «- rest) 



{next: front {/rest: ttw-queuentsetf)) ) )) )))) 



ywhen m d equ e ue message is received, 

jif the value of quouoom 

if* •«N»*3fc them the message mo returned. 

M it is a non-empty sequence, front and reel 

the rest of Us elements, respectively. 

itiw^volm * of queueee it updated. 



;[next:.J is returned* 
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integrity condition which must be satisfied among constituents of the. implementation. The 
following implemtntation invariant statement can express the diagram more formally. 

(Implementation-Invariant: 

if «h«-oueu»-H»H U-a UUPURK-OURUR (!«]» 
then 

( queu— i hat-value S) 

(S u-a {SEQUENCE [§»))) > 

This says: when the state of the actor denoted by the-quMie-ttsolf is expressed by the 
conceptual representation 

{I M PURE-QUEUE [U}h 

the variable qu«MM has the value which is always some sequence actor S whose elements 
are expressed by [!«]. {SEQUENCE [!•]) is the conceptual representation for such a sequence 

Fig. 5.8. 




• • « 
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actor. 

An implementation invariant describes the ma p pin g from the states of an actor 
(the "specif ication space") to the states of the constituents of a fiver implementation for the 
actor (the "implementation space"). 1 Suppose that the behavior of an actor A is specified by 
the state of A before or after its invocation. Then an implementation invariant is used in 
the verification of A in the following way. 

First, the state S of A before the invocation is translated into the state H(S) of the 
constituents of the implementation by a given implementation invariant II. Then the 
implementation [code] is symbolically evaluated and the states of the constituents after 
the invocation are obtained. Next, by using the implementation invariant again, the 
state S' of A, specified as the one after the invocation, is translated into the state II(S*) 
of the constituents. Finally, the states of the constituents obtained by the symbolic 
evaluation are checked to aee if they satisfy those translated states. (See Figure 5.9.] 

In general, given a state T of an actor A and an implementation I for A, an 
implementation invariant for I tells us the relations which must be satisfied by the states of 
the constituents of I to realize the state T. Therefore implementation invariants may be 
one-to-man? mappings. In such a case, when symbolic evaluation of an implementation is 
started, only such relations (holding among the states of the constituents of an 
implementations) are assumed: exact states of each constituent are not used- An example of 
the one-to-many mapping cases is found in Section 7.4.2, Chapter 7. Implementation 
invariants are similar to the inverse of Hoare's abstract functions [Hoare72l and also serve 
as concrete (representation) invariants which he used additionally in proving correctness of 



1. A state in the implementation space is a vector of states of the constituents of the 
implementation. 
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Fig. 5.9. Verification of an actor A Behaving like Information Storage 



<In vocation > 



implementation Invariant 




IKS) 



IKS') 



representations of data structures. Interpretation functions between two formal theories 
studied by R. Nakajima [Nakajima-et-al77] seem closely related to implementation 
invariants. 



5.3.2 Establishing Event Specifications 

An implementation of an actor which behaves as "information storage" is verified 
by establishing each event specification associated with the actor. In this subsection, we will 
illustrate this by using an impure queue-actor as an example. 
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The verification of the implementation of an impure queue-actor is carried out by 
symbolic evaluation. To aid in the exposition of the symbolic evaluation, we augment the 
PLASMA code in Figure 5.7 with situational symbols as shown in Figure 540; This code is 
verified against the contract in Figure 5.2. Below we will establish the two <«vent:~y clauses 
in the contract, which specify the creation and enqueueing events. The dequeuing event 
can be established similarly. 

Establishing ^qtffiTlON ideation 
In the first <cvent:..> clause in the contract in Figure 5.2: 

<<timnt: IT/ create-impure-queue <= [ll 
KreturnK Q*) > 
<po,t-cond: (Q U-* (IMPURE-QUEUE []» ». 

there are no pre-conditions for this event Thus no assertions are entered in the data base 
for the initial situation. 



in 



S pre-cr»»tion * **£!*. 



The let statement in the code declares and initiates a variable qmue e t with an empty 
sequence NS. To record this, the folkwmg asjertkms are entered. 

(n ^initialized-queuees s 
(guawMC kat-value NS) 

(NS ii-a {SEQUENCE [])) 

Then in this situation an actor whose script (i.e. code) is given as the (cum.) statement 
after (tbe-queuexftMff s ... is newly created and returned. This actor is denoted by 
th«-qu«u«-tts*i<. The contract for the creation requires '"two things: (1) that the returned 
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Fig. 5.10. 

(create-impure-queue s 

<s>[] 

{let (queuees initially []) 
than 

— R — 

°initialized-queuees ~ 

(the-queue-itself = 

(cases 
(=> (ng: =new-element) 



,-creste-impure-queue receives an empty sequence. 

ya. variable queuees in declared 

;and initialized with an empty sequence. 

;a queue-actor denoted by the-queue-itself is defined 
fby the cases-statement given below. 



-s 



\when an enqueue message oath an element is received, 
;n o w- o lo m ont is bound to the element. 

received-nq " 

(queuees «- [fqueuees new-element]) ;e new sequence-actor whose elements 

;are the unpack of the value of quay** and new-element 
,*i« created and is stored in queuees. 



- R 

°updated-queuees-nq 

the-queue-itself) 

(=>W7-) 

- R - 

"receiv^d-dq 

(rules queuees 

- fi 

"empty-queuees 

(ex/iauxlctf:) ) 



{an** then the-queue-itself is returned. 
;when en dequeue message is received. 



n"f the value of queuees 
fts an empty sequence. 



ithon the complaint message is returned. 



{=> [sfront !=rest] 
-S 



^f it is a non-empty sequence, front and rest 
;are bound to its first element and the rest of its elements, respectively. 

non-empty-queue** " 

(queuees «- rest) u° he value of queuees is updated. 



-S 



upd«ted-queuees-dq ~ 

{dequeued: front (r«jl: the-queue-itself)) ) )) )) )) ;(««**;...) is returned. 
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actor Q be newly created and (2) that (Q ii-o (IMPURB-QUBUB []» holds. Since the 
returned actor is tto-qtwiM-HMlf, what we need to show is that 
( th«-queue-itsel< i,-a (HI PURE-QUEUE [})) holds, This assertion is translated into the 
following assertions using the assertions in the loferr-ctause in the implementation invariant 
statement given in the previous subsection. [Note that the assertions in the tetore-cteuse 
are instantiated by substituting an empty sequence [J for !•.] 

( queu— t hat-value S) 
(S i*-« {SEQUENCE [W 

These two assertions are matched against the two assertions entered at the node for 
S tnH»l«*d-m*u«*r Therefore it is concluded that the returned actor th*-c*NMM<4tt«<lf has 
the correct interna! structure prescribed by the implementation invariant So the result of 
the event B" cr«aU-impw-qu«u« <- [Q meett its specification. 

Establishing the ENQUEUING specification 

From the instantiation of the event specification for enqueueing: 

<«t*rnt: T y*e--qu«ue-HfH <« inqt A)J 

Knre-eond: tthe-ouam-HteH U-a (IMPURE-QUEUE [|xD) > 

(return*: th«-quwit««W > 

<Dost- CO n4: Nto-tUMm-HuH i*-a (IMPURE-QUEUE [jx AD) » 

which is obtained by substituting ttw-qucwitMH for Q in the contract for 
(IMPURE-QUEUE [„.]) in Figure 5.2, it is assumed that 

ftha-queue-foeft i+* (IMPURE-QUEUE [|x])) 
holds in the initial situation. By the implementation invariant statement, this assumption is 
translated into the following two assertions: [Note that x is substituted for a in the 
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invariant statement.] 

111 initialized-queuees : 
( queuees hat-value $)) 

(S it-a (SEQUENCE [\x])) 

Now the message (nq: A) is sent to the-queue-itself. This message matches against the first 
clause of the case statement. So new-element is bound to A. 

in S raf< , ; „ r>4 . n t ( new-element s A) 

Then the value of queuees is updated by a newly created sequence-actor NS with its 
elements [Iqueuees new-element]. The value of queuees in S,.,^^..,^ is obtained by 
inheriting from Sj n jtj 8 |jzed-queuees' because no updating events took place between the two 
situations. Thus the value is a sequence-actor S. Iqueuees is the result of the unpack 
operation on S, which is !x. [Note that the sequence actor is pure. Therefore its state can be 
inherited from S in j iJa ,j Md _ queu0M .] So the state of the new sequence-actor NS is expressed 
by {SEQUENCE [!x A]). For the assignment of NS to queuees, the new assertion 
(queuees hat-value NS) is entered in the data base. So the following assertions hold in the 
next situation. 

in updated-queuees-nq : 
( queuees hat-value NS) 

(NS it-a (SEQUENCE [!x A])) 

The code tells us that the-queue-itself is returned in this situation. The specification for the 
' nqueuing requires that the-queue-itself be returned and that 

( the-queue-itself it-a (IMPURE-QUEUE [|x A])). 
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So this assertion is translated into the following assertions by the implementation invariant. 

( queueet hat-value S) 

(S i*-a (SEQUENCE [«x A])) 

These assertions are obviously matched against the assertion* entered at the node for 
SupdaUd-^uMs-nq So the e T eul P* e W meets to specification. 

5.4 Discussions Related to Symbolic Evaluation 

The method of symbolic evaluation presented in this chapter has many interesting 
facets and significant implications for other researctf areas besides program verification. In 
this section, we first reflect on our approach to veftftcatton baaed on symbolic evaluation in 
the light of other existing approaches. We then discuss the applications of symbolic 
evaluation. Finally, bur reasoning method employed tn symbolic evaluation will be 
discussed in the context of McCarthy's frame problem. 

5.4.1 Situational Descriptions vs. Predicate Transformations 

Program verification methods based on the Ftoyd-Hoare proof rule* XFloyd67, 
Hoarc69] or predicate transformers [Manna69, Dijkstra76] <in be sumrnariied as follows: 

Given a set of predicates P holding in a situation S, the proof rules or the predicate 
transformer generate a set of predicates P' [from P3 which hold in the next 1 situation 



1. For the case of the proof rules, the next situation is the temporal successor situation, and 
for Dijkstra's predicate transformers, it is the p*edecess«r situation. 
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S'. 



The choice of predicates holding in S determines the generated set of predicates for S'. 
Those choices are made so that desired assertions may be shown to hold in S'. This 
approach is schematically described in Figure 5.11. Note that the predicate transformers 
work backwards. 



Fig. 5.11. Floyd-Hoare-Dijkstra Predicate Transformation Approach 
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In contrast to the approach above, our approach is: 

Given a description D of a situation S, symbolic evaluation produces a description D* 
of the [forwardly] next situation by using contract* and traru-sUuationat rutes. 

A description of a situation is a collection of assertions about states of actors which are 
expressed by conceptual representations. Predicates which hold in a situation ate derived 
from the description of the situation. This approach, which we call the "situational 
description" approach, is schematically described in Figure JM2- 

Conceptual representations not only express states of individual actors in a system, 
but they can also describe how the individual actors are interrelated at various levels. Thus 
the description of situations in terms of conceptual representations is powerful in dealing 
with sharing. Furthermore, descriptions of each situation provide us with sources of 
various information about a program, which U .quite useful for other applications in the 
areas of mechanical program analysis. 



5.4.2 Applications of Symbolic Evaluation 

Symbolic evaluation based on formalisms different from ours has been studied for 
various purposes such as proving properties of programs [Boyer-Moore75X program testing 
and debugging [Boyer-et-al75, King76], program transformation and improvement 
[Burstall-Darlington75] etc. 

Our method of symbolic evaluation can be used in constructing a software system 
called a Programming Apprentice [Hewitt-Smith75, Rich-Shrc*Mf76l which aids expert 
programmers in various aspects of programming activities such as verification, debugging, 
and refinement of programs. In the Programming Apprentice, the purpose of symbolic 
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Fig. 5.12. The Situational Description Approach 
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evaluation is not simply to verify programs against their specifications. By symbolic 
evaluation, we try to gather information about dependencies between program modules. 
Such information is used to understand implications of proposed changes in both 
specifications and implementations in the subsequent evolutional development of the 
programs. 

For instance, suppose that the implementation of «i»^roni^|i^-in1o-anotber used 
as an example of program verification is sent pure queue actors instead of impure queue 
actors. Using the contracts for pure queue actors in Figure 4.2 in Chapter 4, our method of 
symbolic evaluation can easily trace and record I the behavior of the implementation. The 
situational tree produced during the symbolic evaluation aids us in modifying the 
implementation so that it may accept both impure and purr queue actors. Another simple 
example might be the analysis of the behavior of the same implementation when it is sent 
the same impure actor. [That is, one of the preconditions, (Qi no*-** Q2) is forgotten.] 
Furthermore, as reported in [Yonezawa-Hewitt|6], the efficiency of the implementation of 
impure queue actors m terms of consumed storage can be^ revealed by using assertions of 
the form 

«»ctof-l> h mmt mb t mt <«ctor2» 
in the process of symbolic evaluation. 

The situational description approach based on our method of symbolic evaluation 
appears to be quite powerful in pursuing these ends. The symbolic evakiator in C. Rich 
and H. Shrobe's system [Rteh-Shrobe76l which understands LISP programs, is based on a 
method similar to ours. 



- 125- 

5.4.3 The Frame Problem 

In the context of Artificial Intelligence, J. McCarthy and P. Hayes 
[McCarthy-Hayes69] pointed out a problem, called the frame problem, which arises in 
formalizing effects of actions or events taking place in a complex world. A typical example 
of the frame problem is found in formalizing the effects of actions of a robot in a block 
world where the robot carries out various physical tasks. Suppose that the robot has moved 
a block B to a certain location. With this action, the location of B changes, but most of the 
properties of the blocks, such as color, height, and volume, and relations holding among 
other blocks, do not change. To formalize the action "move", it is necessary to specify not 
only which of these properties and relations will change [and how they will change], but 
also which properties or relations will not change. Since the robot is supposed to perform a 
number of different actions, for each action such changes in properties and relations in 
both positive and ne gative sense must be specified. In most cases, rather a small number of 
properties and relations change as the result of a single action, while the rest of them do 
not. Thus the number of such specifications will be unbearably large for a practical system 
if the tasks of the robot and the world in which it works become complicated. 

The same problem arises in the context of program specification and verification. 
In particular, the frame problem becomes serious when one tries to construct program 
verification or understanding systems which must deal with actors whose behavior may 
change with time. To specify the effects of computations tor events], the no-changes as well 
as the changes in the states of objects in a system must be described even if the objects do 
not participate in the computations. If we described the changes and no-changes of all the 
objects in the system in a straightforward way, the same serious problem would arise. 

As presented in the first section in this chapter [5.1.2, 5.1.3], we take a procedural 
approach to this problem. Our reasoning method based on trans-situational rules is 
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powerful in coping with the problem in the domain of Artificial Intelligence as well. R. 
Waldinger has independently proposed an approach similar to ours for dealing with certain 
issues in program synthesis and has discussed its application to Artificial Intelligence 
[Waldinger77]. Those who are interested in comparative studies of the existing approaches 
to the frame problem should see [Sandwall72, Hayes73, Hewitt75, Waldinger77]. 



127 



6. Specifying Parallel Computations 



In this chapter, the specification language introduced in Chapter 4 is extended to 
cover parallel computation. Formal specifications of abstract data type objects which are 
used in multi-process environments are written in the extended language. Examples for 
illustrating our specification techniques include air line reservation systems and bounded 
buffers. An alternative definition of states of actor (objects) is discussed at the end of the 
chapter. 
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6.1 Introduction 

In this section, we will discuss the characteristics of parallel computation which 
make its specification method different from that for serial computation. Our specification 
techniques for parallel computations will be described in the subsequent sections of this 
chapter. 

6.1.1 Communicating Parallel Processes 

In a serial computation, activations of actors take place sequentially and one at a 
time. Thus it is modelled as a set of linear ordered events with each event causally related 
to one another. [Recall the definition of computations in Chapter 3.] In a parallel 
computation, however, more than one activation may take place concurrently. Some events 
are causally related to each other, but some may not be. Therefore, a computation is 
modelled as a set of partially ordered events. A sequence of causally related events can be 
viewed as a "process". From this view point, parallel computations involve multiple 
processes and serial computations a single process. 

If, in a parallel computation, concurrent processes do not interact with each other, 
i.e., no events are causally related between processes, the computation can be viewed as a 
collection of mutually independent serial computations. 

However, there are many reasons for the necessity of interaction between 
concurrently running processes: If arguments in a procedure call are evaluated in parallel, 
a process which executes the procedure body must wait until all the parallel evaluations of 
the arguments are completed. In air line reservation systems and inventory control systems, 
concurrent processes interact with each other by retrieving and updating various 
information in data bases. In operating systems, concurrent processes interact through 
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sharing resources such as main/secondary memories and I/O peripherals. 

In order for such interactions [or cooperations] to be effective and efficient, 
concurrent processes must communicate and synchronize with each other. Therefore in 
specifying interesting behaviors of parallel computations, we need techniques which are 
able to deal with communication and synchronization between processes. In our model of 
computation, such communication and synchronization is realized by chang in g states of 
certain actors. [Cells, buffers and data bases are examples of such actors.] Therefore the 
central issue in the method for specification of parallel computations is to deal with the 
behavior of actors which are used for communication and synchronization. 

States of actors are extensively used in specifying parallel computations as well as 
serial computations. But states of actors in parallel computations [or multi-processor 
environments] need to be dealt with much more carefully than those in serial computations. 
We will discuss this issue in detail in the next subsection. 



6.1.2 Local States 

In describing behaviors of parallel computations, there have been many 
attempts[Milner73, Kahn74, Ashcroff75, Cohe»i75, dwicfci75, KelJer76. Owicki-Gries**6. 
Flon Suzuki77, Lamporr77] to use the notion of the global states of an entire system. The 
global state of a system at a given time is expressed essentially by a vector of states of the 
subsystems. The use of the global states is often motivated by the use of non-determlnlstic 
serial computations for the semantic model for parallel computations. In order to study 
properties of a subsystem, this approach leads to counter-intuitive serialization of 
concurrent events' takmgplkce in unrelated subsystems and it forces us to consider not only 
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changes in other subsystems but also the order in which such changes take place. Thus the 
number of cases to be examined tends to be exponentially targe, but almost all changes in 
other subsystems are irrelevant to the subsystem under consideration. 

In our approach, we do not rely on such notions as the global state and the global 
clock [uniform time reference]. Rather we take a local and relativists view. We assume 
only the local states of individual actors. [Cf. Section 1.3, Chapter U The local state of an 
actor is determined only at the local time associated with the actor. Thus, when the state of 
a computer at some site of a computer network is determined, we do not assume that the 
states of computers at other sites can be defined. The state of an actor is determined at the 
time when the actor receives a message. This timing is particularly Important and useful in 
parallel computations because it is a welt defined moment in a distributed system. [The 
moments of message transmission at scattered computer sites are difficult to compare with 
each other.] Recall that the ordering of arrival of messages with respect to a given actor 
[arrival subordering] is total in our model of computation. [Cf. Section 3.1.3, Chapter 3] 

In Section 4.1.1, Chapter 4, we have defined states of an actor as equivalence classes 
of past histories of messages sent to the actor. As discussed before, this definition 
subsumes, in serial computations, traditional definitions for data-storing objects, whose 
states are determined by their current information content Such traditional definitions are 
inadequate in parallel computations (or muki-procw environmenttl For example, imagine 
a data base system which is concurrently accessed by a number of users. If the state of the 
data base were defined as its stored data, its state at the time of the arrival of an access 
request could not be determined, because the stored informaUon might be being changed by 
previously arrived requests. Also determining the information content inside the data base 
at the time when a request arrives at the data bast is incompatible with our relativistic view 
introduced above. [Imagine a data base system where an access request may be received by 
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a computer site located at one side of the continent while actual data may stored at the 
other side.] 

States of an actor defined as equivalence classes of the past message histories are 
not. affected by the actual activations of the actor. Abo the order of arrival of messages is 
linear (total). These two facts are essential to our specification techniques for parallel 
computations because they guarantee that states thus defined are always well defined even 
if the actor is being activated by the previously arrived messages. In the later sections, 
examples that illustrate the significance of our state definition will be found. In particular, 
a model of interaction between a post office and customers in Chapter 8 will provide an 
intuitive example. 



6.2 Extending the Specification language 

Specifications of the behavior of actors in parallel computations are written in a 
way similar to that in which the behavior of actors in serial computations is specified. 
That is, when given the state of an actor, the behavior of the actor is specified by the 
resulting state changes and the subsequently caused event*. However the major difference 
lies in how the states of actors change and how such changw ar« expressed. To distinguish 
such difference, the specification language introduced for serial computations in chapter 4 
needs to be extended. 
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6.21 Instantaneous State Changes 

Let us try to write a formal specification of a cell actor. A cell actor is used to store 
information. It accepts updating messages of the form {update: <rww-cont«nts» and 
retrieving messages of the form {content*:). Its behavior is expressed informally as follows: 

"In response to a (content!:) message, 

a cell actor returns <contents> which was contained 

in the most recently arrived (update:...) message if such a message exists, 
otherwise it returns its initial contents" 

We would like to express this behavior by using the states of the cell. 1 To express a 

state of a cell actor, we use conceptual representations. For example, 

{CELL {contents: A)) 

expresses the state which is defined as a class of histories of messages whose most recent 

updating message is of the form {update: A). If the cell were used only in serial 

computations, we could specify this behavior by the following two event specifications: 

<evcnl: |[C <= (content*:)^ 

<l>re-cond: (C i*-a {CELL (content*: A))) > 

<rcturn: A > 

<l>o*t-cond: (C i*-a {CELL (content*: A))) > > 

<crcnt: |[C <s (update: B)J 

<l>re-cond: (C U-a (CELL (content*; A))) > 

Krcturn: B > 

<l>o*t-cond: (C i*-a (CELL (content*: B))) > > 

Unfortunately, the above event specifications do not precisely express the behavior of a cell 
in parallel computations, because the states of C expressed in the <po*t-cond:...> clauses are 



1. I. Grcif and C. Hewitt gave a specification of cells which is expressed by axioms about 
events in [Creif-Hewitt75, Creif75l 
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the states at the time A or B are returned, but the state of the cell may be changed by the 
updating messages subsequently arriving before A or B are returned. 

In order to eliminate this impreciseness in the above event specifications, the 
following two points should be made clear. First, states of a cell expressed by the 
conceptual representations must be interpreted strictly in terms of equivalence classes of 
histories of incoming messages. They should not be interpreted to express the current 
contents of the cell. The second point, which logically follows from the first one. is that in 
order to be consistent with the definition of the states expressed by the conceptual 
representations, the state of the cell must change instantaneously when an {update:...) 
message arrives. 

In general, in specifying behaviors of actors in parallel computations through their 
state changes, the fact that states change instantaneously must be taken into account. 



6.2.2 <Ncxt-cond:...> Clauses 

To express the instantaneous state changes in specif icatidns, we introduce a new 
specification language construct, <next-conii..> clauses. This is wsuaUy used in event 
specifications of the following form. 

<cvcnt: £T <== Mj 

<pre-cond: ... > 

<mtxt-cond: ... <ass§rtjon>... > 
<cau.»cd-event: E » 

This means: when an event |[T <*= Mj takes place*, if the preconditions are satisfied, the 
<assertion>s in the <next-cond: ...> clause hold immediately after the event [T <»« Mj and 
continue to hold at least until one of the actors appearing in the < wrtion> s receives the 
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next message. For example, if the < mtrtion> s mention T or M, they continue to hold at least 
until T or M receives its next message. The assertions in the <next-cond:.J> clause can be 
viewed as the preconditions for the next event. A <next-cond:J> clause differs from a 
<po*t-cond-....> clause in that assertions in the <pou-eond:.J> clause hold at the time the 
corresponding caused event take place, but may not hold before the caused event When a 
<noxt-cond:...> clause is used in specifying serial computations, its meaning is identical to 
that for a <po*i-cond:..> clause. The event E in the <c<m»e«f-«tNH«:^ clause must take place 
eventually. It is often the case that concurrent events are caused bv £l <** Mj. In such a 
case, we use clauses of the form <cauud-awmtti (...<«v yn| >„.l>. Other interpretation rules for 
event specifications, such as those for absent clauses, abbreviated forms and scope rules for 
symbols in clauses are the same as for serial computations, tCf. Sections -UJ and 43.3, 
Chapter 4] 

Using this new construct, a specification of the behavior of a cell in parallel 



Fig. 6.1. A Specification of a Cell 

<«M»»t;Xcr« »t*HfffH <g AJ 
<rcturn: C* > 
<pa»l-tond: <C U-a [CELL (content*: AW) » 

<imtmt: £C <» (contenU:)J 

<pm-cond: (C U-a [CELL ifiontomut A))) > 
<nrxi-coni: (C U-* (CELL icmmtoMm A))) > 
Krcturn: A » 

Kutmnt: f C <» (update: B)J 

<pr«-eond: (C i*-a {CELL (content* A))) > 
<if*Yf-r<MNi: (C i»* {CffU. {«•**«*« f>») > 
<rcturn:B» 
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computations is written as depicted in Figure 6.1. <Return:...> clauses are used as an 
abbreviated form of a <cauicd-event:...> clause. When a cell actor is created by the 
create-cell actor receiving the initial contents, we need not use a <next-cond:...> clause in 
expressing the state of the newly created cell, because before the new cell is released nothing 
can happen to change the state of the cell. It should be feinted out that the equivalence 
relation defining the states of a cell (which are expressed by conceptual representations) is 
expressed incrementally by the <pre-cond:~> and <next-con4t~> clauses in the specification in 
Figure 6.1. 



6.3 Examples of Specifications 

In this section, we will discuss three specifications as examples. The first example 
is a specification of a simple air line reservation system. This example illustrates how the 
behavior of systems which process requests on a first-come-first-served basis is specified by 
our technique. In the second example [a specification of semaphores], we will see how 
processes which have requested some actor for resource usages that have not yet been 
granted are dealt with in expressing the state of the actor. The third example is a 
completely external tie. implementation independent] specification of a bounded buffer 
which requires us to express "nQn-£irst-CQmefir«-fer^ 

As was mentioned before, an actor model of a simple post office is studied in 
Chapter 8. It is shown that overall task specif icatlons of the post office can be derived by 
specifications of the individual behavior and mutual interaction of actors in the model. 
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6.3.1 Modelling an Air Line Reservation System 

As an example, let us consider an air line reservation system. For the sake of 
simplicity, we assume that only one flight Is available in the system. A number of travel 
agencies [parallel processes] try to reserve or cancel seats for the flight concurrently. We 
model 1 the air line reservation system as a flight actor F which behaves as follows. The 
flight actor F accepts two kinds of messages, 

ir«*er#e~er-Mtat: <p*— fig f nam e)) and (e« *iwf » w i ll <p m e rn e r - nsm « » . 
When F receives fo*crv<t-a-seat:...), if free seats are left, the passenger name is appended to 
the passenger name list for the flight and the number of free seats is decreased by one, and 
a message {ok-it»-re*erwid;) is returned. Otherwise a message (no-mort-uatu) is returned. 
When F receives (r.aneel-a-teat:...), if the passenger name is found in the passenger name 
list, a message (ok-ita-cancelUd:) is returned and the passenger name is deleted from the 
passenger name list and the number of free seats is increased by one Otherwise a message 
(the- pa **cngcr-nam«-noi- found:) u returned. Furthermore requests by (rwMr«e-a-<eat:...) and 
(c.ancri-a-*cat:...) are processed on a first-come-first-served basis. 

To write a formal specification of the air line reservation system, we need to 
describe the states of the flight actor. For this purpose, we use the following conceptual 
representation 

which describes the state of a flight actor. The number of free seats is <m> and {!pnl} is 



I. E. A; Ashcrof HWfSf gave a flowchart program which models an air line reservation 
system. In his program, each user (or agency) has its own copy of the request handling 
program and all the copies are connected with a single /or* operation. Furthermore, the 
number of users must be fixed. 



- 137 - 

the passenger name list for the flight The formal specification of the air line reservation 
system using this conceptual representation is depicted in Figure 6.2. 

Since the states expressed by conceptual representations in the specification are 
defined as equivalence classes of histories of messages sent to F, the number of free seats 
and the passenger name list given in the conceptual representations does not necessarily 
correspond to those that are actually stored in the system. 1 From the view point of a 
message arriving at F, the states expressed by conceptual representations in < P rc-cond:...> 
clauses are virtual. That is to say, those conceptual representations express the information 
that will be true after all the messages previously arrived at F are processed, although 
currently some of those messages may be being processed or some may even be suspended 
in the request queue. Therefore, only air line reservation systems in which the reserve and 
cancel requests are processed on a first-come-first-served basis satisfy the specification in 
Figure 6.2. 

It is easy to specify the behavior of air line reservation systems which deal with 
more than one flight and can add and remove flights. To do so, one may use conceptual 
representations which express the flight information for each flight. For example, 

MSERV/iTION-SYSTEM {...{flight-i: Ueau-free: <xi»{pa*Kng€r-namc-liu: {!pnl})) ...}) 

may suffice. In this case, the reservation system thus specified processes the reserve and 
cancel requests on a flight-wise first-come-first-served basis. This implies that requests for 
different flights may not be processed on a first-come-first-served basis. The technique to 
specify the flight-wise first-come-first-served processing can be applied in specifying file 

I. If the processing of requests were so fast that each request might be processed before the 
next one arrives, the information expressed in the conceptual representations would 
correspond to what is actually stored in the system. 



-I3»- 
Fig. 6.2. A Specification of an Air Line Reservation System 

<*vcnt: IT create-f light <« Si 
<r>re-cond: (S > 0) > 
Krfliirn: F* > 
<,ta*t-condi (F is-a (FLIGHT (seats-free: $Y (pmssener-nome-list: {})))» 

<ri"M: JF <= (reservc-a-seat: NAME)] 

<prr-cond: (F is-a (FLIGHT (scats- f rem 0) (jKUM«fer-itam«-/ut: {!pni}»J> 
<nct i-ronrf; (F w-o (FLIGHT (seats-free: 0) (passenger-name-list: {lpni}))» 
<rntitrn: (no-mere-sttatt:) » 

(rfljw-2: 

(F m-« (FLIGHT (seats-free: N) (passenger-mameJisi: {!pnl}))) 

(N> 0) > 
Oirn-conrf; (F £*-« (FLIGHT (seats-free: N - 1) (pa««i.^r-n«in«-/W; {|pol NAME}»)> 
<rriurit: (ofc-lfn-rexArwtf.-) >)> 

<evrnt: |[F <= (ranre{-a-«<v*t: NAME)] 

<prr-cond: 

(F m-« (FLIGHT (teat*- free: H) (patsenger-mame-Ust: {Ipnl}))) 

(prtl «•{... NAME „})> 
<iu>i(-ro»<*: (F i*-« (FLIGHT (seats-free: N) (pauengor-mamtt-lisl: {Jpni})»> 
<r«*iurnf frfcg-fHHWHd wuaiW i iw t /*amt;) » 

<pre-cond: 

(F i*-«i (FLIGHT (seats-free: N) (passenger-name-list: {Jpnil NAME !pri2)))» 
<nr»i-«ri»irf: <F u-« {FLIGHT Ueais-free: N ♦ l) (/>«*««#«-»•»«-««<.• {|pntl |pn(2})))> 
<r«n*«i: (0it-it«-ea*c«//e4:) » ) > 
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systems, large data base systems, and disk-head scheduling systems [Hoare74] as long as 
individual files and disk tracks are used on a first-come-first-served basis. 



6.3.2 A Specification of Semaphores 

The behavior of semaphores can be easily specified by our techniques. The state 
of a semaphore is described by conceptual representations of the following form. 

{SEM/IPIIORE [counter. <n» {waiting-q: [!q]» 

where <n> is the number of processes that can still enter the critical section it guards and 
[!q] is the queue of processes waiting to enter the critical section. A specification of a 
semaphore is depicted in Figure 6.3. 

A message sent to a semaphore consists of a request [i.e., either P-operation or 
V -operation], and a continuation actor which will be activated when the request to the 
semaphore is granted. The continuation can be viewed as a process that will be awakened. 
As stated in the Case-2 of the second event specification [for P-operation], when the counter 
is zero, no message is sent to the continuation. Hence the <cauted-event:...> clause has no 
events. In the Casc-1 of the third event specification [for V-operation], two events, 
|[C <= [go-ahcad:)2 and [first <= {go-ahead:)] are caused concurrently. 
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Fig. 6.3. A Specification of Semaphores 

<cvent: ff" c reatc-semaphOf <« fij 
<pre-cond: (H\ 0) > 
<rrl»rn; S* > 
<,,o.«i-rW: (S ts-a {SEMAPHORE (counter: N) (warn** -?: [D)> » 

<r»««Mi: |[ S <== [*r 9 u«*t: (P-»p:) f reply-to: Cfl 
(Co*/*-/: 
<ltrc-cond: 

(S i.«-« {SEMAPHORE {counter. N) (miffer-*: [}» ) 
(N>0) > 
<*«.* »-r«W: (S m-o {SEMAPHORE {counter. N - 1} (iMbfe*-* QUI > 
<rnuW-ct>cni; £C <s (go-ahead:)"} >) 

<pre-cond: {$ i»-a (SEMAPHORE (fiommton 9Y (umiti**-*: [ W») > 
<itr*i-ronrf; (S i*-e {SEMAPHORE [cottar. 0) (iwiiiii,-*: [Iq Q]») > 
<mn*rd-rvmtK {) > ) > 

<«t<ent: f S <«e [r<?<ruc*l: (f-o#K>, reply-to: Cfl 

</>rr-rW: (S i*-o (SEM /1PI10KE (coanter: 0) {uxuOmr-o: [iir»\ |rwt]))) > 
Oi<vv«-rW: (S i*-a {SEMAPHORE (counter. 0) (waiting-*,: [lr«tt]))) > 

</>rc-rW: (S *«-« {SEMAPHORE (counter: N) (iMJiinr^: Q))» 
<nrx«-ronrf : (S fo-« (SEMAPHORE (counter. N ♦ 1) (««itiii # -,: [)))) > 
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6.3.3 A Specification of a Bounded Buffer 

As a simple example of specifications for actors which do scheduling of incoming 
requests, we specify a desirable behavior of a character buffer of a fixed sire N with which 
concurrent processes communicate to one another. 

A buffer actor B accepts two kinds of requests, (remove:) and {append: < character >), 
and it can hold at most N characters. Characters are appended or removed from the 
buffer on a f irst-in-f irst-out basis. But requests are not necessarily granted on a 
f irst-come-first-served basis, because a character should be appended only when the buffer 
is not full and it should be removed only when the buffer is not empty. This implies that 
when the buffer is empty, {remove:) requests must be suspended until the buffer becomes 
non-empty by an (append:...) request arriving later. Similarly, when the buffer is full, 
{append:...) requests must be suspended until the buffer becomes non-full. Therefore, in 
determining external states of the buffer, we must take into account such suspended 
requests (waiting processes). 

To express the states of the buffer, we use conceptual representations of the 
following form. 

{BOUNDED-BUFFER (q a : [-.])(«,; [...])(Mtring: [...])) 

q n and q r denote queues of suspended messages for (append:...) and (remove:) requests, 
respectively. String denotes the string storage used as a buffer. [Remember that the states 
expressed by the conceptual representations are defined in terms of the equivalence classes 
of the past message histories. So q a , q r and ttring do not necessarily correspond to the 
queues of requests which are actually suspended or the string of characters which are 
actually stored.] 

In figures 6.4 and 6.5, we give a specification for the behavior of this bounded 
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buffer. The first event specification in Figure 6.4 describes how the buffer is created. 
Note that the two queues q a and q r as weU as the strirtg storage are empty when the buffer 
is created. 

The second event specification in Figure 6.4 describes the behavior of the buffer 
in response to a message M for a (rem***) request Note that the message M explicitly 
contains a continuation C. There are three cases depending upon the stale of the buffer B 
at the time when the message M arrives. Com- I is the one in which the string storage is 
empty, and no messages for {/append:^.) requests are suspended &e, q a » 0], and messages 

' """ * " ' ■' " ' ."" ~ <-<<-> _ ■ ■'■■» m I I IIWII I lW. f»^pWPW#.| l»< III.I H III W ■■ II I IJIH l l l l tl ipi wi .. I W II II II II II III ill! M l I I I III ^ 1 III I I l-l 

Fig. 6.4. A Specification of a Bounded Buffer of Sise N (Creation and Removing a 
Character) 

<rvcnt: If create-bounPed-butfT <s fjj 
<r«»iuriK B^> 
<pou-cond: (B is-a {BOUNDED-BUFFER {q a : []){«,; [)){Mrimg: []})) » 

<«Mvnl: |[B <= Mj 

where M s [r«<|K0M: (remotw:) reply-to: C) 

(Caw?-/: 

</>rr-ron<f: (B i*-e [BOUNDED-BUFFER (q a : QKf r * [MXtfrtajs [J») > 
Oirri-eoit* (B m-o {BOUNDED-BUFFER (e,: D><V N y MBC***"*: Q)» > 
<cautcd-#»entK {) >) 

{Cate-2: 

<pr*-c(md: (B i«-« {BOUNDED-BUFFER (o^t []Wv HKatrfN*: [X {■}))) > 
<nert-eon«l.%<B fc-a {BOUNDED-BUFFER (««•* DHv OMpttfar IM»> > 
<cau««4-etMHit: £C <» (ramMwi' X)J >) 

<pre-romd: 

(B i*-a {BOUNDED-BUFFER {q^ [MM |xJMf ,; QKtfriiif : [X !•]))) 

a*ni«hOX ftl) « N) 

(MM = [rrquert: {append: XX) reply-to: CC}) > 
<n«vi-ro«rf: (B m-o {BOUNDED-BUFFER (e^r tlxJMv QXtfriiif : U« XX]))) > 
<cau««j-etwfii<: (J[C <■ (removed: XQ, |CC <• (ownhmI-Amm:)]}} » > 
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for {remove:) requests may or may not be suspended. [i.e., q r s [ly] 1 ]. In this case, the 
message M is enqueued at the end of q r and no events are caused. When the string storage 
is not empty and both q r and q a are empty (Cate-2), the first character X in the string 
storage is deleted and sent back to the continuation C as a reply message {removed: X). 
Cosr-3 is the one in which the string storage is full [i.e., l«ngth([X !»]) = N], at least one 
message for an {append:...) request is suspended [i.e., q a = [MM !x] ] and no messages for 
{remove:) requests are suspended. In this case, the following change in the state of B 
happens: the first element MM in q a , which is of the form 
[request: {append: XX) reply-to: CCJ, is deleted from the queue, the character XX is added at 
the end of the string storage, and the first character X in the string storage is deleted. 
Then, two events are caused concurrently: [C <= {removed: X)J where X is sent to the 
continuation C and j[CC <= {appcnd-done:)J where the acknowledging message for the 
message MM for an {append:...) request is sent to the continuation CC. (Cf. the remarks 
below.) 

The behavior of the buffer in response to messages for {append :...) requests is 
described by the event specifications given in Figure 6.5. This event specification and the 
one for {remove:) requests in Figure 6.4 are symmetrical: By exchanging the roles of q a and 
n r and the conditions expressing the upper bound and lower bound of the length of the 
buffer, one is obtained from the other. 

It should be pointed out that the six cases for the state of the buffer considered in 
the event specifications in Figure 6.4 and 6.5 are mutually exclusive and enumerate all cases 
of the states which the buffer can be in if it is created with q r q a , and the string storage 



1. Recall that [«y] can be an empty conceptual sequence. Cf. Sections 2.2.3 and 2.3.5, in 
Chapter 2. 
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empty. One should be reminded that the states of the buffer are defined in terms of 
equivalence classes of past histories of messages «ni |o it and that the state changes 
described in the specification are instantaneous as they are expressed by assertions in the 
<ncxt-cond:...> clauses. Thus, q r can be non-empty only if uring is empty and q a can be 
non-empty only if $tring is full, and consequently, ? r and «, cannot be non-empty at the 



same time. 



From the specification given in Figures 6.4 and 6*, it is easy to observe the 



Fig. 6.5. A Specification of a Bounded Buffer (Appending a Character) 

<ricnt: |[B <= Mj 

where M « {request: [append: X) reply-te: CJ 
(Casc-1: 

<pr<>-cond: 

(B »V« (BOUNDED-BUFFER (q a : [In])( V Waring: [!«]))) 
««nc<h([!s]) * N) > 
<ncxt-cond: (B w-o [BOUNDED-BUFFER {q a : [Ix M])^ [])($tring: [!•])» > 
<cnu»* d > e ve nt *: {) » 
(Case-2: 

<pre-cond: 

tB i>« {BOUNDED-BUFFER iq a : [J)^- U^nnr. [!•])» 
(l«nf ttyfMX N) > * , 

<n<.ri-cond; (B i«-o [BOUNDED-BUFFER (qj £J)(^- Q)(ttnii*: [Is X}))) > 
<raux<!d-<!tM?nt: £C <» (append-doM:)"J >) 
[C<fw3i 

<pre-eond: 

(B w-a (BOUNDED-BUFFER [q a : [])(,,,• [MM Iyj)u>iHn#: []))) 
(MM = [r«7«uMi; (rvmotw:) reply-te: 0C}> > ''*" 
<n**i-coit«r: (B fo-a [BOUNDED-BUFFER {q a : [])(*,; [!y])(«rin*: []))) > 
<cause<t-ct>cfit«: {[C <s (appentf-rfam:)], [CC <b (rwmaW: X)] } >) > 
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following property of the bounded buffer: It is always the case that the character removed 
in response to the nth {remove:) request is the one which was appended by the n-th 
(append:...) request. More formally, 

Property (First-In-First-Out) 

Let E[ = |[ B <== [rcriucxt: (remove:), reply-to: Cj]J 

denote the i-th event where B receives a (remove:) request, and 
E^ = |[B <== [requeti: (append: Xj), reply-to: T]J 

denote the j-th event where B receives an (append-....) request. 
For any n > 0, if both E' and E* exist, 

then there exist an event E - £C„ <== [reply, (removed: X n )fl such that E n -act-> E. 



6.4 Behavioral Equations 

As noted in the beginning of the previous section, our specification method is 
roughly summarized as: 1 

"Given a state of an actor A, the behavior of A in response to a message M is 
expressed by the new state of A and the finite concurrent events caused by the 
event |[A <== MJ." 

The method suggests to us that a state of A can be viewed as a certain mathematical 
function F A whose domain is a set M of actors (or messages) and whose range is a direct 
product of a set S A of states of A and a finite power set P (T x M) of a direct product 
of a set T of target actors and M. [Note that T x M corresponds to a set of events.] 

F A : M — > S A xP(TxM). 



I. For the sake of simplicity, we do not take into account the states of the message M and 
the actors involving in the caused events. 
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Whether or not the function F^ exists as a well defined mathematical object needs 
to be proved, but we do believe that the following isomorphism would be shown to hold by 
a certain domain construction for S A similar to that for the lambda calculus done by D. 

Scott[1972l 

S A Z (M -— > S A xP(TxM>>. 

where ( > ) denotes a set of continuous functions with a specified domain and range. 

The construction of such domains will establish the mathematical meanings of actor states 
which are described by conceptual representations. 

The above isomorphism is inspired by the notion of processes proposed by R. 
Milner [Milner73]. Extending the work of D. Scott, R. Milner has expressed the meaning 
of a program by the notion of processes. He defines his notion of processes by the 
following isomorphism. 

PS (V > P xV) 

which says that a set P of processes is isomorphic to a set of continuous functions from a 
domain V of values to a direct product of P and V. There are fundamental differences 
between his approach and ours, due to the framework of the two approaches. Our 
approach is based on the computation model in which a computation is defined as a 
partially ordered set of events and for each actor, a total order [called an arrival ordering] 
is defined. In Milner's approach, a computation is defined as a composition of processes in 
which parallelism is expressed as a non-deterministic choice of processes by "oracles". The 
introduction of oracles forces us to consider uninteresting details of the interleaving of 
concurrent processes. Furthermore, the lack of arrival ordering makes it difficult to deal 
with the issues of fairness and starvation. 

C. Hewitt and H. Baker [Hewitt-Baker77] have shown that the behavior of a pure 
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actoi can be defined as the minimal fixpoint of a continuous functional. This result does 
not apply to the whole set of actors. Thus we hope that the approach exemplified by the 
above isomorphism will be able to deal with the whole class of determinate actors. 



-148- 



7. Verifying Parallel Computations 



In this chapter, our techniques for verification of actors which are used in parallel 
computations (in multi-process environments) are presented. In the first section, a special 
class of actors which are used for synchronization and scheduling of requests is described. 
To illustrate the verification techniques, an air line reservation system and a bounded 
buffer which are implemented with such a class of actors are considered in the subsequent 
sections. 



- 149- 

7.1 Introduction 

As noted earlier, if, in a parallel computation, concurrent processes do not interact 
with each other, the parallel computation can be viewed as a collection of mutually 
independent serial computations and its specification is given as the collection of 
specifications for the serial computations. The verification of such a parallel computation 
is nothing but a repetition of the verifications of serial computations. Consequently no 
special techniques in addition to those for serial computations are required. 

In the previous chapter, we have developed specification methods which are 
applied to computations in which interactions among concurrent processes are involved. 
Since interactions between processes are performed by sending message* to certain kinds of 
actors, our specification methods focus upon the behaviors of such actors. We nave given 
various specifications for such actors. But those specifications merely express the behavior 
that users or implementors of such actors assume or hope they have. There is no guarantee 
that actually implemented actors behave correctly with respect to their specif icattons. 

In this chapter, we first discuss now such actors are implemented and then explain 
how they are verified. As examples, we win verify implementations of an air line 
reservation system and a bounded buffer. 



7.2 Serializes 

In our model of computation, we use a special class of actors, called 
5mWizm[Atkinson-Hewitt77], to realize synchronization and scheduling of message 
transmissions in a uniform and modular fashion. In this section we explain the concept of 
serializes and give precise specifications for their behavior. The language constructs for 
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serializers. and their relationship to other synchronization primitives such as monitors 
[Brinch-Hansen73, Hoare74], are discussed in [Atkinson-Hewitt771 

7.2.1 Concept of Serialize™ 

The purpose of a seriatizer ii to enforce orderly uses of resource-like actors [such 
as I/O devices, message buffers, directories, files, data base systems e£c] by concurrently 
running processes: Some resources must be used one at a tune to guarantee correct 
functioning of hardware, some should be used on a certain priority basis for special 
demands and efficiency reasons, and some should receive messages in a proper order for 
maintaining their integrity. 

In order to control access to a resource, we encase the resource in a seriatizer to 
intercept the messages sent to it. Any processes which need to use the resource can send a 
request message to it freely, but all request* are first received by the serializer. The 
serializer sends the requests to the resource at an appr opriate time depending upon the 
physical requirements of the resource and the scheduling and priority adopted for the 
resource. No request message arrives at the the resource directly. W« caM the arrival of 
such a request message at the serializer, a serializer r«$itrtr and the arrival at the resource 
of a request message which is sent by the serializer, a resource request. 

In order for a serializer to properly perform such synchronization and scheduling 
of requests, it must know various information such as what state the resource is in, which 
requests are being suspended, and which are being granted. To keep such information 
accurate, the reply (or results) produced upon the completion of the use of the resource is 
first sent to the serializer, and some of the information kept in the serializer is updated, and 
then the serializer returns the reply as a response for the original serializer request We call 
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the former event a resource reply and the latter a serializer reply. 



serializer request 



7y 





serializer reply 



Vf 



resource request 



« 



resource reply 



.. ' 



^///////////////////%>, 



Thus a typical sequence of events associated with the use of the resource encased 
by a serializer starts with a serializer request and then the resource request is made when it 
is appropriate. The resource reply follows upon the completion of the use of the resource, 
and finally the serializer reply takes place as a response to the original serializer request. 
The diagram above shows this sequence of events. 



7.2.2 Behavior of Serializes 

As was mentioned above, a serializer maintains certain kinds of information to 
make resource requests take place in such a way that desirable resource usage is 
accomplished. To store and update such information, a serialzer may have three types of 
information storage: queues, crowds and counters. Below we look into the behavior of a 
serializer in more detail by explaining the functions of such information storage. 

Queues in a serializer are used to store request messages which have arrived at the 
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serializer. but whose corresponding respur« re^j^ h^e np^ yet ujtfn place. They also 
record the order of the arrivals of such request messages. A serializer may have more than 
one queue to sort out request messages by their types. {For example, requests for reading 
data are stored in a queue different from the one for write requests.) Suppose that a 
message [rt> q ae»t: RQ rrply-to: C) arrives at a serialize/ G. (This is a serializer request 
event.) If the request RQ should not be sent to the resource encased by G at that time, the 
message [rtnfu«tu RQ r*ply-io:C] is put at the rear of a queue in G. Later on, when the 
message is at the front of the queue and certain conditions for synchronization or 
scheduling are met, the message is removed from the queue and a new message 
[rc<7ur«t: RQ reply-to: BP] is created and sent to the resource This is a resource request 
event. RQ is the request contained in the original message sent to G. BP is a newly created 
actor, called a buck passer, which has the following special properties: 

(1) BP remembers (knows about) the serializer G by which it is created. 

(2) BP remembers the continuation 1 C contained in the original message sent to G. 

(3) BP shares the same arrival ordering with the serializer G.* 

The third property means that the order between the arrival of a message at G and the 
arrival of a message at BP is always defined. (More intuitively, BP and G share the same 
arbiter.] Since BP is sent to the resource as the continuation in the message for the resource 
request, BP eventually receives a reply from the resource, if the resource replies. This is a 
resource reply event. Although we explained in the previous subsection that the reply from 
the resource is sent to the serializer G, the above account is more accurate. However, the 



1. See Sections. 3.1.2 and 3.1.3. in Chapter 3 for the definition of continuation. 

2. The model of computation defined in Chapter 3 does not assume this kind of 
"combined" arrival ordering. This assumption U solely for it*r simplicity of explanation. 
By letting the buck passer BP send itself to the serializer G together with the message it 
received, this assumption can be eliminated. See appendix V; 
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previous explanation is justified by the property of the buck passer BP which shares the 
same arrival ordering with the serializer G. 

Crowds in a serializer are used to store buck passers which are created when 
requests are sent to the resource by the serializer. The existence of some buck passer BP in 
a crowd indicates that the corresponding use of the resource has not been completed yet, 
because BP is taken out from the crowd only when BP receives the reply from the resource 
(which means the completion of the resource usage). [It is the third property of a buck 
passer described above that allows the serializer to eliminate the buck passer from the 
crowd upon the arrival of the reply at the buck passer.] More than one crowd may be used 
in a serializer to distinguish the types of resource requests being granted. For example, by 
having two crowds, a serializer encasing some file is able to know whether the file is 
currently being read or written. 

Let us consider the behavior of a serializer in a resource reply event. Suppose that 
a buck passer BP in a crowd CR receives a reply RP from the resource. If certain 
synchronization and scheduling conditions are met, the serializer takes out the front element 
[request: RQ rcply-io: C] from one of the queues, and a new request message of the form 
[request: RQ reply-to: NBP] is created and sent to the resource. When the new request 
message is created, a new buck passer NBP (which remembers C) is created and put in a 
crowd (which may be different from the crowd CR). At the same time, the old buck passer 
BP is deleted from CR. The serializer has another responsibility. It must send the reply RP 
(just received by the buck passer BP) to the continuation remembered by BP. This is the 
serializer reply event. Recall that BP is created for remembering the continuation originally 
contained in the message sent to the serializer. 

Counters in a serializer are used to record various numbers about events associated 
with the serializer. For example, a counter records the difference between the numbers of 
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resource reply events of various kinds. A simple example of the uses of a counter will be 
found in Section 7.4. 



7.2.3 One-at-at-Thne Serlalim (An Example) 

The behavior of seriali*ers informally explained in the previous subsections can be 
rigorously specified in our formalism. To iUustrat* how their behavior is expressed in our 
formalism, we give a formal specification of a simple serialiw called cme-at-a-Ume in 
Figure 7.1. A resource encased by this serialize U used, at most, by one process at a time, 
and on a first-come-first-served basis. 

The first event specification in Figure 7J says that when an actor 
er«at»-on«-at-a-tim« receives a resource R, it creates a serializer G which ha* one queue and 
one crowd, both of which are initially empty. 

The behavior of 6 in response to * request message depends on the state of G. If 
both the queue and crowd are empty U/Om^h) of thacecond event specification in Figure 
7.1], a buck passer BP is created and put in th« crowd and a request message containing BP 
as the continuation is sent to thf resource it Otherwise (G»#-*i, the request message is 
enqueued and no, event is caused, 

The third event specification «ys4hat whan a buck passer BP which is inside the 
crowd of G receives a reply message, if the queue of G U empty (Cow- J :X l BP is deleted 



1. Being able to check whether or not the queue of G is empty relies on the assumption that 
the state of G can be determined at the time when the buck paase* BP receives a message. 
This assumption is implied by one of the general properties of buck passers that a buck 
passer shares the arrival ordering with the seriaUieV bj which jfff cmnxi. In Appendix 
V, a specification of one^t-A-time JeriaUwrs which does not rely on this assumption is 
given. 
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Fig. 7.1. A Specification of a One-at-a-Ttme Scheduler 

<evrnt: H" create-one-«t-a-1tme <g Rl 
<return: G* > 
<l>ost-cond: (G it-a (ONE-AT-A-TIME (queue: [])(cro*od: {})(re$ouree: R))) » 



<cvcnt: |[G <== Mj 

where M = [requett: RQ reply-to: C] 
(C«*<*-/: 
</>r«-ro«d: (G i$-a (ONE-AT-A-TIME (queue: [])(crowd: {})(retouree: R)» > 
<ncxt-cond: 
<G is-a (ONE-AT-A-TIME (queue: [])(erowd: {BP*})(iw©*r*« R))> 
(BP i*-a (BUCK-PASSER (continuation: Oiserialixen G)» > 
<cou.«f»rf-fiwcnt: |[R <=s [requett: RQ reply-to: BP]J >} 
(Ca.w-2: 
</)ro-co«rf: (G iji-a (ONE-AT-A-TIME (queue: [tx})(crou>d: {BP})(resource: R))) > 
<nert-cond: (G i.^-a (ONE-AT-A-TIME (queue: [!x M]Her»«rf: {BP})(r««Ntrce: R)» > 
<cauHid-eventK {} »> 

<frrnr: |[BP <== [r«?p/y: A]]j 

m here (BP u-a (BUCK-PASSER (continuation: Oberializer. G)))) > 
(Co**?-/: 
</>r<>-roni£: (G i*-a (ONE-AT-A-TIME {queue: [))(erotod: {8P})W*oarce: R)» > 
Oirn-cond: (G u-a (ONE-AT-A-TIME (queue: [])(cro»d: {})(re*mrce: R)» > 

<rau *r</-r«<»M: £C <=s [r«p/y: A]J >) 
(Coxfl-2: 
</>rc-ron«f: 

(G j«-a (ONE-AT-A-TIME (queue: [WM IXJKeiw* {BP})(r«warce: R)» 

(WM = [r«<7uext: RQ reply-to: CC]) > 
<ri«»irj-con«f: 

(G ix-a (ONE-AT-A-TIME (queue: X!x]){co>wrfj ^ipP*})(rwMWfce: R») 

(NBP i*-« (BUCK-PASSER (continuation: CCKwrwJiw: G))) > 
<cou«>rf-e»;cnt»: { fl*C <u [rep/y: A]] , £R *■■ [«?»««: RQ reply-to: NBP]] } »> 
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from the crowd and the reply message is sent back to the continuation^ remembered by BP. 
If the queue is not empty (Cotc-2:), the front element WM which is _a suspended request 
message sent to G before is dequeued and a newly created buck passer NBP replaces BP in 
the crowd. Then a serializer reply event £c <« [reply Afl and a resource request event 
£r <== [rcqum: RQ reply to: NBP]J take place concurrently. 

Before ending this section, we should mention several properties of the 
one-at-a-time serializer which are easily derived from the specification given in Figure 7.1. 

If a resource R is encased by a one-at-a-time serializer before R becomes known to 
other actors, there is no way to access the resource directly. 1 In order to access the resource, 
first a request must be sent to the one-at-a-time serializer. This property holds for any kind 
of serializer (not just for one-at-a-time seriaiizers). We call this property the resource 
confinement of serializers. More formally, 

Property (Resource Confinement of Serializers) 

Let E - E crcate-a-resource <— : [regueu: I reply to: *r«a4e-a-sfwfaer fl and 

E l " !T croaUea-teriifa*r <== [request: ft reply-to: CQ such that £q -act-> Ej, 

where I is used for the creation of a new resource R. 
and let G be a serializer created by Ej. 
If there exists no event EE ,■* £ A <» [request: R reply-to: TJJ 
such that Eq — > EE ~-> Ef, 
then for any event £R - £R <= [request: RQ reply-to: ?fl, 
there always exists afrevent E « fff -«■£ [reqmettfUQ replyto: ?fl 

-such that*E' ! wt £ *^V. r ' '' '" '"" 

We need to give the definition of an assertion (A is-used-serially) to state the 
propei ties of one-at-a-time serializers. If the assertion (A it-uted-teriolly) holds, an actor A 



1. We assume that the creator of R does not release any information which makes it 
possible to have access to R. 



-157- 

does not receive any message until the current invocation of A is completed. Consequently, 
if the invocation is not completed, no more messages arrive at A. More formally, 

Definition (A is-uscd-serinlly) 

If there exists an event Ej « [A <== [request: RQj reply-to: C ( ]]], 
then 

if there exists another event Ej - |[A <== [request: RQ: reply-to: C:]J 
such that i * j and Ej -arr-> A Ej, 
then there must exist EEj - |[Cj <== [reply. ?)J 
such that E j —> EEj —> Ej. 

Property-I (Serial Use of Resource) 

If an resource actor R encased by a one-at-a-time serializer, then (R it-used- serially) holds. 

This property is derived from the fact that the number of buck passer actors in the crowd 
of the serializer is always one at most. 

Definition (A ix-guarantccd-to-reply) 

For an event E = [A <== [request: RQ reply-to: C]]|, 
there always exists an event EE - £C <s* [reply: ?]J such that E -act-> EE. 

Property-II (Guaranteed Resource Access) 
Suppose that the resource actor R encased by a one-at-a-time serializer G satisfies 

the following condition: if (R is-used-serially), then (R is-guaranteed-to-reply). 
Then, for any event E - |[G <== [request: RQ reply-to: 7]]|, 

there always exists an event ER - £R <= [request: RQ reply-to: ?]]J such that E -act-> ER. 

This property is derived from Property-I by induction on the number of messages that 
have already arrived at G. 
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Property-lII (First Come First Resource Access) 
Under the same premise given in Property-II, 

for any E,, Ej where E k = |[G <== [request: RQ k reply-to: C k ]]], k «= i, j, 
if E, — > G Ej, 
then ERj — > E; 

where ER^ = 1[R <== [request: RQ k reply-to: ?]J, k «■ i, j. 

This property is derived from the fact that requests sent to G are recorded in the queue of 
which preserves the order of arrival. 
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7.3 Verifying Implementations of Actors I 

In this section, we discuss our techniques for the following class of verification 
problems. 

"Given an actor A which shows some behavior in serial computations (i.e., when it 
is used serially). Suppose that an actor B is implemented as a one-at-a-time 
serializer encasing the actor A. Then we would like to verify that even if B is sent 
messages concurrently, B shows the same behavior as A does in serial computations." 

This problem is not trivial because the states of A and B which are used to describe their 

behavior in specifications are expressed by different conceptual representations. The 

essential part of the verification is the use of the mapping (implementation invariant) 

between two different conceptual representations. The technique illustrated below is an 

extension of the one used for the verification of actors behaving as information storage 

discussed in Section 5.3, Chapter 5. The verification of implementations using more 

complicated serializes is discussed in the next section (7.4). 

In what follows, as an example of such verification problems, we will demonstrate 

that the implementation of an air line reservation system given below meets its specification 

depicted in Figure 7.2 (which is the same one given in Figure 6.2 in Chapter 6). 

7.3.1 An Implementation of an Air Line Reservation System 

We implement an air line reservation system which is supposed to meet the 
specification in Figure 7.2 in two steps. First, we implement a flight data actor which 
satisfies the specification in Figure 7.2 as long as it is used serially. Then it is encased by a 
one-at-a-time serializer. [The flight data actor corresponds to the actor A in the above 
problem statement.] 

The code given in Figure 7.3 is an implementation of such a flight data actor. It 
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Fig. 7.2. A Specification of an Air Line Reservation Sy*tem 

<«»>«»«/: |[cr«ato-f light <« S] 
<l**-rond: (S > 0) > 
Krclurtt: F* > 
<lx>st-cond: (F i*-a [FLIGHT (teala-fntK S) (pattenger-namo-litt: {})))» 

<«v*nt:. |[F <= (r«T««rwT-o-«!at: NAME)] 
(rnsr-l: 

</»r#.-ro H rf; (F iit-o (FLIGHT (s«ai*-fr*e: Q) ifxutengttr-name-iist: {!pnl})))> 
Oirvi-ronrf: (F U-a {FLIGHT (teati-fret,: 0) (patunger-mmme-liM: {lppi})))> 
<rrinrn: (no- more-Mali;) >) 
(ranc-2: 
</>re-cond: 

(F i*-a (FLICHT (MKtu-/re«: N) (paueNf«r-ii«m«-Jui: {!pni}))) 
<N>0) > 
<nt>xt-c.<md: (F iVa (FLIGHT (Moii-/r«: N - 1) (/xuj«i,«-mn»#-tt.<; {Ipni NAM£}»)> 
<rriurn: (ok-itM-renervad:) >)> 

<«?wif: £F <= (cnncei-a-wrai; NAME)] 
(ro*«- /: 
<ftrit-r0nd: 

iri*-aWIJGIITlM!at$-fri!e:N){pa$*mg0r-a*m*-li$uil&}m 

(pnl #{... NAME ...})> 
O^ri-concf: 4F !*-« (FLIGHT (tcalt-fnm: N) (/»«** j*r-*«m*-tt*l: {!pnl})))> 
<murn: (ih<t-pat*eHger-n*me-tM-fou*d:) » 

<prt>-rond: 

(F i.«-o (FLIGHT (*«at$-fre«: H) (pauengw-name-U*: {IpnJl NAME |pnl2})))> 
<npxi-co«rf: (Fi*-« (FLIGHT (<o«t«-/r««: N + 1) (poww gg f wa w»-ft*t: {Ipnll |pn)2})))> 
<rrinrn: (ok-H*-cmncelUd:) > ) > 
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Fig. 7.3. A Code For a Flight Data 

(create-flight-data =s) = 
{In (seats-free initially s) ,o wxriabfo seats-free t* initialized to s. 

(passenger-name-list initially (create-empty-set)) 

' / " , » ;o variable passenger- i« initialized to an empty set. 

(cases 

(5> {reservc-a-seat: =name) ;tohen a {reserve-...) menage is received, 

(rules (seats-free = 0) ;if the value of seats-free is 

(=> yes {no-more- seals:)) ;then a {no-more-seals:) is returned. 

{=> no ;otherwise 

(seats-free ♦- (seats-free - 1)) ;the value of seats-free is decreased by one 

{add name to passenger-name-list) ,-name is added to the list. 

{ok-its-reserved:)))) ;a message {ok-its-reserved:) is returned. 

(=> {canccl-a-scal: =name) ;u>hcn a {cancel-*.) message is received, 

(rules (name in passenger-name-list) ;if name is found in the passenger name list, 

(=> yes ;then 

{delete name from passenger-name-list) ,-name is deleted from the list 

(seats-free ♦■ (seats-free + 1)) ;the value of seats-free is increased by one 

{ok-its-cancelled:)) ;{ok-its-canccllcd:) is returned. 

{=> no {the-passenger-name-not-found:)) )) )) ;otherwise {the- passenger-...) is returned. 



should be noted that if the flight data actor were sent more than one message concurrently, 
anomalous results would be caused. For example, if {reserve-a-seat:...) and {cancel-a-scat:...) 
message are sent concurrently, {no-more-seats:) message might be returned even if there are 
still vacant seats. Therefore this actor must be used serially. 

We give a specification of this actor in Figure 7.4. Though this specification looks 
similar to that for the air line reservation system in Figure 7.2, there are important 
diffferences. In this specification conceptual representations of the following form are 
used. 

{FUCIIT-DflT/\ {seats-free: ?){passenger-name-list: {...))) 
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Fig. 7.4. A Specification of A Flight Data Actor 

<evcnt: [[ ereate-flight-data <= S"fl 
<prc-cond: (S > 0) > 
<rctvm: FD* > 
<post-cond: (FD is-a (FLIGHT-DATA (seats-free: S) (pastener-name-list: {})))» 

<cvcnt: [[FD <= (rcscrvc-a-scat: NAME)]] 
where (FD is-used-serially) 
(case- 1: 

<prc-cond: (FD is-a (FLIGHT-DATA (scats-free: 0) (passenger-name-list: {»pnl})))> 
<rrlurn: (no- more- scats:) >) 

< t >osi-cond: (FD i«-o (FLIGHT-DATA (scats-free: 0) (passenger-name-list: {!pnl}))» ) 
(case-2: 

<prc-cond: 

(FD is-a (FLIGHT-DATA (seats-free: N) (passenger-name-list: {!pnl})» 
(N > 0) > 
<rctvrn: (ok-its-rcscrved:) > 
■< rnt\d: 
is-a (FLIGHT-DATA (scats-free: N - 1) (passenger-name-list: {!pnl NAME})))»> 

<cvcnt: ([FD <= (canccl-a-scal: NAME)]] 
trhcrc (FD is-used-serially) 
(casc-h 

<prc-rond: 

(FD i*-« (FLIGHT-DATA (scats-free: N) (pajien^er-nomtf-/wl: {!pnl})» 
(pnl st {... NAME ...})> 
<rcturn: (thc.-passcngcr-namc-not-fov.nd:) > 

<,xt*i-cond: (F i\-a (FLIGHT-DATA (seats-free: N) (poMon^»r-nom«-/iiii: {!pnl})))> ) 
(rojsf»-2: 

</ir*?-ronrf: 

(FD i*-« (FLIGHT-DATA (scats-free: N) (pai«wiff<?r-name-/iit: (Jpnll NAME !pnl2}»)> 
<rctum: (ok-its-canccllcd:) > 
ipof.i-r.ond: 
(FD i*-a (FLIGHT-DATA (seats-free: N + 1) (poMBH^<»r-nttme-/iit: {"pnll !pnl2})))>» 
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Notice that assertions of the form (FD i*-u*cd- t crially) are given in the u,her« clauses of the 
second and third event specifications. This means that those event specifications are valid 
only if FD is used serially. Furthermore, <pou-coni: ..> clauses are used instead of 
<»f*<-ro»rf.„> -clauses. This means that assertions in the <poH-cond:.> dauses hold at the 
time when the caused events take place. 

The following property holds for the flight data actor because all the <cw«ir...> 
clauses have the corresponding <r«i«r«.o clauses. This property is used in the verification 
in the next subsection. 

Pioperty-lV: If (FD i»-u,c4-teriaU y ), then (FD trguanntoeiHo-ntdy) 



7.3.2 Verification of the Air Line Reservation System 

The implementation is completed by encasing the flight data actor by a 
one-at-a-time serializes That is, the implementation of the er«.t«-flight actor is expressed 
by the following PLASMA code 

(creat«-flig ht as) s (craaU-ona-at-a-iinw (cr«at«-fltght-data «)). 

Below we demonstrate that the above code meets the specification of tne air line reservation 
system shown in Figure 7.2. The symbolic evaluation of the code 

(cr«at«-or»-at-a-tim« (cr«at«-fiight-data s)) 
reveals the following facts: 

(1) an actor FD is created by JT creata-flight-data <« ,J f/rom the specif ication in Figure 

7.4.], 

(2) a serializer G is created by iT create-ona-at-a-tima <« FDj [from the specification in 
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Figure 7.1.] and 

(3) the two actors satisfy the following assertions immediately after the creation of G. 
(G is-a {ONE-AT-A-TIME {queue: []){erowd: {}){reiource: FD») 
(FD is-a {FUGIIT-DATA {seats-free: %){passengcr-namc-list: {}))) 
We will establish that G satisfies the specification of the flight actor (air line 
reservation system) given in Figure 7.2. The specification of the flight actor G is written in 
terms of conceptual representations of the form: 

(G is-a {FLIGHT {scan- free: 7){patsenger-name-litt: {...}))) (*) 

(Notice that F in the specification is instantiated as G.) On the other hand, G is 
implemented as a one-at-a-time serializer that encases the flight data actor FD, which is 
expressed by the following two assertions: 

(G is-a {ONE-AT-A-TIME {queue: [...)){erou,d: i...)){resource: FD))) 
(FD is-a {FUGIIT-DATA {seats-free: l){p*ssengcr-name-li*t: {...}))) (**) 

This means that we have two views of G: an external view expressed by (*) and an internal 
implementation expressed by (**) above. In order to show that the implementation satisfies 
the specification written in terms of the external view, we must establish a certain relation 
between the two views. Such a relation is similar to implementation invariants used in the 
verification of an actor behaving as information storage [Cf. Section 5.3, Chapter 51 
The relation we need is: 

"If G satisfies the assertion 

(G is-a {FLIGHT {scats-free: N) {passenger-namo-list: {!pnl}))) 

in a situation where G receives a message [request: RQ reply-to: ?], 
then FD always satisfies the assertion 

(FD is-a {FLIGHT-DATA {seats-free: N) {patten ger-name-list: {£pnl})» 
in the situation where FD receives a message [request: RQ reply-to: ?]. " 
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We actually prove the validity of this relation in the next subsection 7.3.3; this relation is 
assumed in the subsequent discussion. The following is the formal statement of the above 
relation. 

<lmplr mentation-invariant: 

if (G h-a (FLIGHT (scats-free: N) (passenger-name-list: {!pnl}))) in S 
where S = Sit (|[G <== [request: RQ reply-to: ?]J) 
then 

(FD is-a (FLIGHT-DATA (scats-free: N) (passenger-name-list: {!pnl})» in S' 
where S' = Stf(|[FD <== [request: RQ reply-to: ?]J) >. 

Sit(Z) expresses the situation where an event E takes place. The implemenation invariant 
can be viewed as the counterpart of an " invariant" in parallel process environments, which 
was first introduced by C.A.R. Hoare [Hoare 1972] to show correctness of implementations 
of data structures used in serial computations. (See the remarks in Section 5.3.1, Chapter 5.) 

Now let us demonstrate the verification of the implementation against the 
following event specification given in Figure 7.2. 

<errm: |[F <= (rcscrvc-a-scat: NAME)J 
(casc-1: 

<pre-cond: (F i»-a {FLIGHT {seats- free: 0) {passengcr-name-list: {!pnl})))> 
<next-eond: (F is-a (FLIGHT {seats-free: 0) (passenger-name-list: {!pnl})))> 
<return: (no- more-scats:) >) 
(c.asc-2: 
<prc-cond: 

(F is-a (FLIGHT (seats-free: N) {passenger-name-list: {!pnl}))) 
(N > 0) > 
<ncxt-cond: (F is-a (FLIGHT (scats-free: N - 1) (passenger-name-list: {!pnl NAME}»)> 
<return: (ok-its-rcscrved:) >)> 

There are two cases to be considered. We only consider the (Case-2~.) clause. The 
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one-at-a-time serializer G receives a {reuirve-a-neat: NAME) request RQ. Since the flight data 
actor FD is guaranteed to reply if it is used serially (from Property-lVj, the specification for 
a one-at-a-tim« guarantees that the {re$ervo-a-teat: NAME) request RQ is received by FD (from 
Property- II). To know the state of the flight data actor FD at the time of the arrival of RQ, 
the above implementation invariant is used. Since the state of G at the time of the arrival 
of RQ at G is described as: 

(G u-o {FLIGHT Ucat$-frec: N) {pauenger-name-liit: {Ipni}))), 

the state of FD at the time of the arrival of M at FD is described as 

(FD it-a {FUG IIT-D AT /Htcatt- free: ti)ip™mnger-imma-li*:{lpri}))). 

Then the (Cnsa-t...) clause in the <«*«:...> clause of the 5 specif nation for flight-data actors 
in Figure ?.* is referred to. Since the precondition that FD must be used serially is satisfied 
(from Property-}), the lCau-2~.) clause of the specification for flight data actors in Figure 

7.4 tells us that 

(1) (ofc-tm-rMcrtW:) is returned, and 

(2) the state of FD is now expressed as: 

(FD i*-a {FLICIIT-DAT/l («jc»- free: N - i) {piiaenger-iwme-tut: 'f Ipni NAME}))). 

(1) is what the <renw|i;„> clause in the above event specification requires. 1 To complete the 
demonstration, we must show that the assertion - 

(G tVo {FLIGHT (ncat-froo: N - 1) {pa$$enger-name-lut: {Ipni NAME}))) 

in the <ncxt-r,ond:...> clause of the above event specification holds when G receives the next 



I. More precisely, {ok-Ut-reterved:) is first sent to the serializer G and then G returns it. 
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message RQ\ To do so, again the implementation is used. It translates the above 
requirement as follows: 

M (FD is-a {FLIGHT-DATA {seal- free: N - 1) {pattemger-name-litt: {Ipni NAME}))) 
holds when FD receives RQ'. " 

This is guaranteed by. <2) because FD does not change it* state until the next message RQ* 

arrives at FD. Thus Case-2 is shown. Ca$e-1 may be shown analogously. The event 

specification for [G <= {canccl-a-*cau NAME))J is also established analogously. 

The demonstration above assumes that no one can have access to the flight data 

actor FD except through the serializer G. This assumption always holds because the flight 

data actor FD created by IT create-flitht-dati <g tj is sent directly to the cr««t»-orT-«t-a-timo 

actor and never released outside the newly created on«««t-«-tim« serialiier G. [Cf. the 

PLASMA code in the beginning of this subsection and Property (Resource Confinement of 

Serial izers).] 

7.3.3 Establishing the Implementation Invariant 

The verification in the previous subsection relies critically on the use of the 

following implementation invariant. In this subsection we will establish the validity of this 

implementation invariant. 

<lmplcmcntation-invariant: 

if {Gi*-a {FLIGHT {*cat$~fr CC :N) (paitcngcr-name-lut: {lpn\}))) in & 
where 8 = 5tt(£G <» [reqm*sli RQ reply-to: ?J) 
then 

(FD u-o {F LIGHT-DATA {&#* fret* N) {p***eng*r-name-Uu: {lpn\}))) in S' 
where S' « Stt&O <** [n^uett: RQ reply-lo: fj> >. 

(Proof) The proof is done by induction on the number M of messages which have already 

arrived at G. 



-168- 

< Induction Baso 

M = 0: Since no message has arrived before, when the first message 
[request: RQ reply-to: C] arrives at G, G is in the same state as it was in at the time of its 
creation. So the state of G is expressed as 

(G u-a {F 1. 1 CUT Ueatt-free: SHpetmngcr-name-litt: {}))). 
Since G is created as a one-at-a-time serializer and its queue and crowd are initially empty, 
the state of G is also expressed as 

{Gi*- a {SERIAUZKH( q u*ue:[]Hc*>wd:{}){r<!t<mrce:FO))) and 

(FO i>« if UQUT-Wffin beats-free: SHpasseHger-name-lm: {)))) 
Then from the "guaranteed resource access" property of G (Property-II). the following event 
is caused. 

|FQ<k [request: 8Q reply-to: ?jj f 
When this event occurs, FD is still in the same state as it was in at the time of its creation 
because "resource confinement" property of seriaHiert is satisfied. So the state of the FD is 
expressed as 

(FD U-a (FLlGIfT-DATA {teats- free: SHpenenger-name-litt: {}))) 
Hence the induction base is proved 

< Induction Hypbthesis> 
M « k: We assume that the following relation holds. 
if (G i*-a {FLIGHT {seats-free: N) {pastenger-nome-litt: {!pn4}))) holds 
in Si7(|[G <== [request: RQ k reply-to: ?Jj) 
then (FD is-a {FLICIIT-D/ITA (matt-free: N) {pattenger-name-litt: IJpnl}))) holds 
in 5«{£FD <=« [request: RQ k reply-to: if} 

< Induction Step> 

M = k + 1: Let us assume that the antece4etit of the j^du^jon hypothesis holds. Then we 
must do a case analysis according to the type of the request of k-th event 
Case-1: RQ R = {reserve-a-teat: NAME), and N>0. 

The state of G immediately after the k-th event JG <m* [teq*esu RQ|< reply-to: ?0 is 
expressed as 

(G is-a {FLIGHT {seats-free: N - i) (passeng cr-mime'liu: (Ipn) NAME)))) 
(by the specif ication of the flight actor ih Figofe'T^. 

This is the state of G when the k ♦ 1 st message [request: RO^n reply-to: t]J arrives at G. 
By the "guaranteed resource access" property of G, "the event 

E m [ FD •<■* [re***** *Q k reply-tot 1] 
always takes place. From the induction hypothesis, the state of FD at the time of this event 
E is expressed as 

(FD i»-a {FLIGllT-D/lT/l {seats- free: N) (passenger- name-list: {!pnl}))) 
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Therefore, by the specification for FD in Figure 7.4, the state of FD after the invocation 
initiated by the event E is expressed as 

(FD is-a (FUCIir-D/IT/1 {seatt-free: N - 1) {patten ger-name-litt: (!pnl NAME}))) 
We now claim that this is indeed the state of FD at the time the k ♦ I st message 
[revest: RQ k+1 reply-to: ?] arrives at FD. This claim is justified by the fact that no message 
arrives at FD between [request: RQ k reply-to: ?] and [reouett: RQ k+1 reply-to: ?]. This fact is 
guaranteed by two properties of a one-at-a-time serializer, the "Confinement of resource" 
and the "First Come First Resource Access" (Property-Ill). 

Other cases are shown in a similar fashion. (End of Proof) 

The above proof relies on the following facts: 

(1) When the one-at-a-time serializer G encasing the flight data actor FD is created, each 

component [such as teatt-free and patten ger-name-litt] of the conceptual 
representation expressing the external state of G is the same as the corresponding 
component of the conceptual representation expressing the state of FD. 

(2) As the specifications for G and FD show, such components of conceptual 
representations for G and FD change in the same way in response to the same 
request, provided that FD is used serially. 

(3) The serial use of the resource encased by a one-at-a-time serializer. 

(4) The "Resource Confinement" property of serializers. 

(5) The "First Come First Resource Access" property of a one-at-a-time serializer. 



7.4 Verifying Implementations of Actors II 

In the previous section, we discussed the verification of implementations which use 
one-at-a-time serializers. The resource actor encased by a one-at-a-time serializer receives 
requests in the same order as the one-at-a-time serializer does. That is, the one-at-a-time 
serializer have the first come first resource access property [Property-Ill in Section 7.21 In 
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this section, we will discuss the verification of implementations using serializers which do 
not have the first come first resource access property. The heart of verification in this case 
is the use of implementation invariants, as it was in the eaie fot imptementattons using 
one-at-a-time serializers. To find an appropriate implementation invariant for a given 
implementation requires human ingenuity, fn what fbno^^^wiWe^larn the verification 
of an implementation of a bounded buffer against the specif kation depicted in Figure 7.5. 
[This specification is identical to the one given in Figures 6:4 and 63.1 



7.4.1 An Implementation of A Bounded Buffer 

We consider the following PLASMA implementation of a bounded buffer. 

(creaU-bounded-boffer (J) a (creatiHHlHe^-teliediiler {er*^^ [flj 

Namely, the bounded buffer of length N is implemented as a serializer B which encases a 
string storage actor S where S is created by r ci^aWttrlng-tteraaa <■ [fl and B is created by 
r create-buffer-scheduler <« S]. Note that S is encased by B without becoming known to 
other actors. Thus the resource confinement property of serializers is satisfied. 

The behavior of the string storage actor k is described by the specification in 
Figure 7.6. Its states are expressed by conceptual representations of the following form. 

iSTRINC-STORAGB [-]) 

When it is created, it contains no character. It accepts (apptmit <characf«r» and (remeve:) 
messages. As stated by assertions of the form ($ it-uttd-urtaUy) in the when clauses, the 
behavior described in the specification is guaranteed only when $ is used serially. 

The creation of the serializer B is described by the following event specification. 
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Fig. 7.5. A Specification of A Bounded Buffer 

<evcw. [T create-bounded-butfer <= TVO 
<rcturn: B*> 
< n osi-cond: (B l»-a {BOUNDED-HUFFER W a t Q^ [}HMring; [J))) » 

<fimi: |[ B <= Mj 

where M = [requett: {remove:) reply-to; C] 
(Case- 1: < P re-cond: (B u-e iBOUNDED-BUFFER (o ft : []Mv [lyJ)U*ri**: []»> > 

<nc*i-cond: (B w-o {BOUNDED-BUFFmAl a : [])<V H* M])(*irin<r: []))> > 
<rnux««f-ff«<?H«*: {} >) 
{Case-2: <pre-cond: (B i*-n {BOUNDED-BUFFER <<*„: £}Mf ,-* [JM^rin/r: [X !s]))) > 
<nc*i-cond: (B w-« {BQUNDRD-BUFFER te a :^)(v UHwrta*: !!«]))) > 
<cau«?rf-«!fN??it: J[C <= (removed: X)J >^ - 
{Case-3: <pre-cond: (B i*-o {BOUNDED-RUFF BR (* e ; [MM |x)Mv [P^rin*: [X !«]))) 
(length([X !t}) * N) 

(MM = [r«i/ucil: {append: XX) reply-to: CC]) > 
<nrirt-cond: (B w-o {ROUNDED-BUFFER ^fe a J ifxJM<r r * E]H«ri»*: [!« XX]))) > 
<cau*<?d-ev*fttf: {£C <= (removed: X)}, [CC <« (ap/Mitd-doite.Oj} » > 

<*»i.wii:|[B <= Mj 

where M ^ [requett: {append: X) reply-to: C] 
{Case-1: <pre-cond: (B is-a (HOUNDED-DUFFER (o^ElxJHf^f ED(«rt»#: [!»]))) 
(len E th([!s]) = N) > 
Oic*t-cond: (B i*-e {BOUNDED-BUFFER l* a t f|x MJXfl,; [])(«lrin*: [!■]))) > 
<cau.scd-event»: {) » 
(CW-2: <prc-cond: (B it-a {BOUNDED-BUFFER (v HHgy tDUlrwitf: [»s]))) 
dength([!s]) < N) > 
<ncri-cond; (B w-e {BOUNDEfcBUF FER {* tt : t]Hv,i HK*tring: £|« X]))) > 
<caused-event: |[C <= (append-done:)J >) 
{Case-3: <pre-cond: (B i*-a {BOUNDED-BUFFER {q a : [])(«,; [MM lyPGurirt*: []))) 
(MM * [r«<7ue*t: (remove:) repljf-te: CCJ) > 
O.ori-cond: (B i*-o {BOUNDED-BUFFER f* a : QHoy HylX"*™*: []))) > 
<caused-evcnts: {|[C <= (append-done:)], £CC <« {removed: X)J} >) > 
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Fig. 7.6. A Specification of a String Storage of Length N 

Kevent: r croato-string-ttor w 0* [fl 
<r fit urn: S* > 
<p»xt-cond: (S it-a (STRINC-STOR/iCE [J)) » 

<etwtl: |tS <= (append: X)J 

where (S i*-u*ed-«0ri«$fy) ' 
(Cow-I: < P re-c**d: (S u-« {STRING-STORAGE [tx]» 
(length(xXN) > 
<ri?iurn; (app«ni£-<fon«:) > 

<po«-a»Mfc (S i*-« (STRJNC-STORACR fix X])) » 
(Ca««-Jj <pre-«Hi* (S **-* (STR/AIC-«TW?/K»tM)) 
(l«ngtMx*iW > 
<rolarn: Storage- full:) > 
<po*t-cond: (S u-a (STRING-STORAGE [fx])) » > 

<ct.'f»i(: [ S <= («imoi»i«)3 

ifl/iwn (S ii-«Mi-Mr»/lyy 
(C<i*0-J: <pre-r.ond: (S u-a (STRING-STORAGE [X !x])) > 
<return: (removed: X) > 

<po»t-cond: (S ft-a (STRING-STORAGE [fx X}» » 
(GoM-i» </>rc-c«nd: (S u-o (SIW NGSTORWE \ J)) > 
<relurn; (j«ora#e-cmpl j-:) > 
<po»#-i»Hd: (S to* (STRING-STORAGE [J» » > 

Oncm: IT create-buffer-icheduler <» S*B 

<,MT-rond: (S M-a (STRINC-STOR/iCE [§xj» > 

<ro/ifrn: B* > 

<posi-cond: 

(B is-a(SCllEDUUiR (counter: Q)($ m : U)($ p : [])(er»«(t {})(re«ouree: S))) 

(S i*-o {STRING-STORAGE [|x]» » 

As expressed by the conceptual representation in the <pott-cond:J> clause, this serializer has 
a counter (initially 0), two queues, q a and $ r (both are initially empty) and a crowd (also 
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initially empty). The counter is used to record the number of characters stored in the string 
storage. The crowd is used to contain buck passers. The existence of a buck passer in the 
crowd indicates that the resource is being used. q a and q r are used to record suspended 
(append-....) and {remove:) requests, respectively. 

The behavior of the serializer B in response to {append:*.) and (remove:) requests 
are described the event specifications depicted in Figure 7.7 and Figure 7.8, respectively. 
Let us look at the behavior of B when it receives a message M of the form 

[requeu: {append: X) replyHo: Cj> 

Case-1: if no {append:) requests are suspended [i.e. $^ is empty], the string storage S is 
not being used [i.e. the crowd is empty], and there is room for the new character X [k < N], 
then the {append: X) request with a newly created buck passer BP which remembers the 
original continuation C is sent to S. The state change, of B reflects this: the counter is 
increased by one and the crowd now contains the buck passer BP. 

Case-2: if the conditions for Case-1 do not hold, the message M is enqueued at the rear 
of ? ft . 

Figure 7.7 also includes the specification of the event in which the reply 
{append -done:) from S in response to an {append:) request is received by the buck passer BP 
which is currently stored in the crowd of B. When BP receives {append-done:), the request 
suspended in the front element of either Q r or $ a is picked up and sent to the string 
storage. If both queues are not empty, $ r has priority over Q a . There are three cases for 
this event. Note that the counter k indicating the current length of the string storage 
cannot be when BP receives an {append-done:) reply, because a new character has been 
just appended before the reply is produced. 

Case-1: if no {remove.) requests are suspended D.e. $ r is empty], and either the string 
storage is full [i.e. k = N] or no {append:...) requests are#«pended D-e., <} a is not empty], then 
the reply is returned to the original continuation remembered by the buck passer P, but no 
message is sent to S. 

Case-2: if there are some suspended {remove:) requests [i.e. $ r is not empty], then the the 
front element M of <j r is taken out, and the corresponding (remove;) request is sent to S with 
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Fig. 7.7. The Behavior of the Scheduler in response to an [Append:..) Request 

<<mvmi: j[ B <== M]j where M = [rcquett: {append: X) replyto: C] 
{Caxe- 1: 

<prr-ronrf: (B iVn [SCHEDULER {counter: k)($ B : [])($,; [!y])(cr<M««*: {})(r«Jource: S») 

(k < N) > 
<next-rond: (B iVa {SCHEDULER {counter: k ♦ l)($ a : [JM^ H/])(c»«rf.' {BP*})(r««wrc«: S))> 

(BP i*-o UiUCK-P/ISSER {continuation: CKxerimlUer: B)))> 
<cau*#««f-ffWrti: |[S <== [requctt: {append: X) reply-to: BPfl >) 

<prr-rond: (B ix-a {SCHEDULER {counter: kM^lMMV [iyJMcrowrf: {!z})(re«mre«: S)» 

(v (x * []) (z |i {}) (k = N» > 
<nexi-cond: (B i.<-a {SCHEDULER {counter: k)($ ft : [«x M])^- [fy])(cro»rf: {l*})(rc«©urce: S)»> 
<rouji('(/-* , i'('nl»: {} >)> 

<evenl: UJBP <== [reply: {append-done:)]^ 

where (BP ix-a {HUCK-PASSER {continuation: C){terialixer: B))) 
(Ca*c-J: 

<pn-tnnd: (B iii-a {SCHEDULER {counter: k)($ fl : [!x])($,; [Pfcrourf: {BP})(re«>urce: S)» 

(v (k = N) (0<k<N A x = [J) )> 
Oirri-coitrf: (B ix-a {SCHEDULER {counter. k)($ B : [|x]X9 r ' [»<»•"»* {})(r««mrc«: S)» > 
<r.auxed-event: |[C <»= [reply: {append-done:)jJ » 
(C««»-2: 

<prr-roi»d: (B ix-a {SCHEDULER {counter. *){q a : [!x])($,: [M !y])(cro»d: {BP})(re«ouree: S))) 
(k > 0) 

(M = {requexl: {remove:) replyto: CC}J> 
<next-cond: (B ix-o {SCHEDULER {counter, k - l)($ s : [ix])^ [!yl){cn»i«l: {NBP*} ){re$ource: S))> 

(NBP iVa {HUCK-PASSER {continuation: COUerialixer: B)))> 
Orausfrf-rwhi*: {|[S <== [requeat: {remove:) re ply- to: NBPO |G<«* [rwpfy: {append-done:)]J )» 
{Caxe-3: 

<pre-rond: (B ix-a {SCHEDULER {counter: k)($ ft : [M |x])(^ r - [])browd: {BP})(re*ource: S))) 
(0 < k < N) 

(M = [requcxt: {append: XX) replyto: CCJ) > 
<n««jri-rond: (B *«-n {SCHEDULER {counter: k ♦ 1)($ B : {!x])(^- ntfe™** {NBP*})(re«>urce: S»> 

(NBP ix-a {HUCK-PASSER {continuation: CC){Mcrializer. B)))> 
<r«u.<f?rf-rtf?ni*: {|[S <== [re^ucil: (append: XX) replyto: NBP|J fC <=» [reply: (append-done:)]]] }>» 
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Fig. 7.8. The Behaviors of the Scheduler in response to a {Remove:..) Request 

<event: |[B <== M]] whore M = [request: {remove:) reply-to: C] 
(Casr-i: 

< n ro-cond: (B is-a (SCHEDULER {counter: k)tf n : [!x])($V [})(crou>d: {}){r«j.ourr«r: S))) 

(k > 0) > 
<r,r.ri-rW: (B is-a {SCHEDULER {counter: k - 1)($ Q : t'x])^- [])(crow,rf: {BP*})(rcj.ourcr: S») 

(BP is-a (RUCK-PASSER (continuation: C)(serializcr: B))» 
<cnnsrd-eveiu: [[S <== [request: (remove:) reply-to: BP]J » 
(Cnse-2: 

<,>rc-cond: (B i*-« (SCHEDULER (counter: k)($ a : [Jx])^' [!y])(cr i«J: {!z})(r M ourcr: S))) 
(V (y * []) ( 2 * {}) (k = 0))> 

<next-c,md: (B i.<- a (SCHEDULER (counter: k)($ a : [!x])(^ [ly M])(crW: [U))(re source: S)))> 
<rau.«rrf-rrr>Ms; {}>)> 

<<•"<""•■ 1[BP <== [rr^/y: (ramowJ: X)]]] 

uhrre (BP iVa (RUCK-PASSER (continuation: C)(*crializer: B))) 
(Case-1: 

<pre-cond: (B is-a (SCHEDULER (counter: k)($ a : [])($,; [ly])(crou,d: {BP} Xnuoaree: S)» 

(v (k = 0) ( Q < k < N a y = [] ) ) > 
<next-cond: (B is-a (SCHEDULER (counter: k)($ ffl : [])<$,; [!y])(cro«rf: {})(rc*ourec: S))) > 
<cn„ sod-event: |[C <== [rcp/y: (removed: X)0 » 
(Case-2: 

< f >re-co„d: (B is-a (SCHEDULER (counter: k)($ tt : [M IxJ)^ [ly))(crou>d: {BP))(re$ource: S))> 
(k< N) 

(M = [request: (append: XX) reply-to: CC])> 
<nr.ri-ri.nd: (B is-a (SCHEDULER (counter: k + l)($ a : [!x])($ r - [!yJ)(eroit>(f: {NBP*})(r«.jiourcr: S))) 

(NBP is-a (RUCK-PASSER (continuation: CC)(scrializer: B))» 
<ra./5rrf-rrrn(*: {[[S <== [n« 9 uasf: (append: XX) rcp/y-lo: NBP]J |[C <== [repjy: (rcmotwd.- X)]]j}» 
(Casr-.?: 

<pre-cond: (B iV« (SCHEDULER (counter: k)(ff a : [])($,; [M !y])(croti,d: {BP})(rwoarcfl: S))) 

(0 < k < N) 

(M = [request: (remove:) reply-to: CC]) > 
<iirr<-ror«of: (B is-a (SCHEDULER (counter: k - l)(Q a : [])($,: [ly])(crou>d: {NBP*})(r«ourcr: S))> 

(NBP is-a (RUCK-PASSER (continuation: CC)(serializer: B)))> 
<caused-eveius: {|[S <== [request: (remove:) reply-to: NBP]]J |[C <== [reply, (removed: X)]]]}»> 
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a new buck passer NBP and concurrently the reply is sent to the original continuation C. 

Case-3: if no (remove.) requests are suspended [i.e. q r is empty], there are some suspended 
{append:...) request [i.e. q a is not empty! and there is room for a new character in S [i.e., 
< k < N], then the (append:...) request at the front of <j a is granted and sent to S with a 
new buck passer NBP. and concurrently the reply is returned to the original continuation C. 

It should be noted that ail the three cases are mutually exclusive and enumerate all 
cases of the states which B can be in when BP receives a [reply' (nppend-done:)} message. 
The behavior of B in response to (remove:) is described in Figure 7.8 in a similar way; the 
roles of q a and q r are symmetrical and conditions expressing the upper bound for the 
counter is replaced by the lower bound. $, has priority over $ r when a buck passer BP 
receives a {removed: ?) from the string storage. 

7.4.2 Verification of a Bounded Buffer 

In order to show that the implementation of the bounded buffer given in Figures 
7.7 and 78 satisfies the specification given in Figure 7.5, we need the implementation 
invariant which is the mapping between the states of a bounded buffer used to write its 
specification and the states used for describing the implementation. More precisely, we 
need the mapping from the set of states, called the "specification space", expressed by 
conceptual representations of the form 

(BOUNDED-BUFFER (qj l-Mq/ [~))(Mrimg; &-])) 

to the set of states, called the "implementation space", expressed by conceptual 
representations of the form 

(SCHEDULER (counter: IHQj [.JM^ [~.])(firwdi {_})(rfliourc«: $)). 

For this purpose, we use the following implementation invariant: 
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// a bounded buffer B is in the state (of the specification space) 
which is expressed by the conceptual representation 

(HOUNDED-BUFFER (q a : [«x])( V [ly))($lring: [!s]» 

then 

B is in one of the states (of the implementation space) 

which are expressed by the conceptual representation 

(SCHEDULER (counter: k)($ fl : [!xx Ix])^ [!yy ty])(crou>d: {U})(rc*ouree: S)), 

and the following constraints must be satisfied 

(1) [!stored-in(S) !character6-app«nd«d(xx)] = [!characters-removed(yy) !s] 

(2) length(stored-in(S)) = k " 

characters-appended(xx) means the sequence of characters that will be appended by the 
sequence of (append:...) requests denoted by xx. characters-remov«d(yy) means the sequence 
of characters that will be removed by the sequence of (remove:) requests denoted by yy. 
stored-in(S) means the sequence of characters stored in the string storage S. 

Note that q n and q a share x and q r and q r share y at their tails. <j a and q r denote 
the queues of requests which are actually waiting inside the scheduler. Thus xx and yy in 
n a and <7 r denote the sequences of actually suspended requests that are considered (at the 
external specification level) to have already been processed, [x and y have not been 
processed yet.] The first constraint in the above implementation invariant says: the 
concatenation of the character string that is actually stored in S and the sequence of 
characters that will be appended by xx is equal to the concatenation of the sequence of 
characters that will be removed by yy and the character string that is considered (at the 
external specification level) to be stored in tiring. The second constraint says that the 
counter k indicates the length of the character string stored in S. 

Since, for given x, y and s, only the relation (or constraints) that must be satisfied 
by xx, yy and k is specified, the above implementation invariant defines a one-to-many 
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correspondence from the specification space to the implementation space. (Cf . Section 5.3.1, 
Chapter 5) Namely, for a given state U in the specification space, the implementation 
invariant II give a set 1I(U) of the corresponding states in the implementation space. See 
the diagram below. 




Specification Space> U #CT { • H(U) } implementation Space> 



To verify the implementation against the specification in Figure 7-5, for each event 
specification in the specification, the implementation must be verified. The diagram in 
Figure 7.9 illustrates the verification for an event £ ■ [BXv Mj. T and V are the states 
of the bounded buffer B given in the <pre-c»ni:J> and <n*ict-*ondiJ> clauses (of the event 
specification for £), respectively. II(T) and II(T0 are the sets of states (in the 
implementation space) obtained by applying the implementation invariant II to T and T\ 
respectively. 

To establish the event specification, we must first show that if the bounded buffer 
B is in a state belonging to I I(T) before the event E, B is in a state belonging to II(T') 
immediately after £. To show this, we do not have to deal with individual states in II(T) 
and II(T'). We use the relations among the constituents of the implementation which define 
1I(T) and ll(T'). [Of course, such relations are obtained from the constraints given in the 
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Fig. 7.9. Establishing an Event Specification 



E = |[B<==M]1 
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implementation invariant.] By using the description of the implementation given in 
Figures 7.7 and 7.8, we obtain (from the defining relation for II(T)) the relation which 
defines the sec X of states in which B can be immediately after E. We check to see whether 
or not the obtained relation satisfies the denning relation for H(T'). i.e., we check whether 
or not X is a subset of II(T"). If the obtained relation satisfies the defining relation for 
II(T'). it is verified that the state of B immediately after the event E is T* in the 
specification space. 

But this does not mean that the implementation satisfies the <next~cond:...> clause. 
We must show that the state of B in the specification space does not change until the next 
request message (either {append:...) or (remove:)) arrives at B, because at the implementation 
level (i.e., when B is considered as a scheduling serializer), a buck passer in the crowd of B 
may receive a reply message from the string storage S and consequently, the state of B 
which is currently one of states belonging to X may not belong to II(T') after such a reply 
event. Therefore we must also show that the state of B stays inside II(T'), which means 
that such reply events do not change the state of B in the specification space. To do so, we 
check if the relation defining the set Y of states in which B can be immediately after the 
resource reply event satisfies the defining relation for HOT). 

To complete the verification of the event specification, we must show that the 
events given in the <cnu*cd-cveni$:..> clause eventually take place. To do so, we use the fact 
that the sequence of requests xx in $ c and the sequence of requests yy in f r are eventually 
removed and sent to S. This is easily done by checking the implementation given in 
Figures 7.7 and 7.8 and the specification of the string storage given in Figure 7.6. 
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8. Modelling a Post Office 



In this chapter, we discuss an actor model of a simple post office which is an 
intuitive example of systems, such as operating systems and multi-user data base systems, 
which are characterized by complex concurrent internal activities. In the first section, an 
informal description of the post office is followed by formal specifications of the 
individual behavior and mutual interaction of the components of the model. In the second 
section, the specification of the overall functions (task specifications) of the post office is 
stated formally. In the last section, we demonstrate that the task specifications are satisfied 
by the individual behavior and mutual interaction. 
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8.1 A Model of a Simple Post Office 

In this section, we present the actor model of a simple post office. The behavior 
of each component in the model is described by our specification techniques and the overall 
propei ties and effects of the post office as a whole are stated formally. Furthermore, using 
this model as an example, we would like to shed light on some of the interesting issues 
related to distributed information processing systems. 

8.1.1 Overview of the Model 

An informal description of activities in a simple post office is: 

A number of customers and mail collectors visit the post office, possibly simultaneously. 
The post office has only one door for customers and collectors. Inside the post office, there 
is a counter section which has several counters and a mail box comer which has a mail box. 
After a customer enters the post office through the door, if he needs stamps, he goes to the 
counter section, otherwise he goes to the mail box corner. At the counter section, a customer 
gets the stamps he needs and then, if he is carrying tetters, he goes to the mail box corner, 
otherwise he goes out of the post office through the door. Customers are served at the 
counter section on a first-come-first-served basis, but the time spent at the counter varies 
from person to person. At the mart box corner, a customer puis all the tetters he has been 
carrying m the mail box and goes out through the door. A collector also enters the post 
office through the door and then goes to the mail box corner. At the mail box corner, the 
collector collects all the mail in the mail box after waiting in the queue, if there is one, and 
then he carries the collected mail out of the post of f ice through the door. Customers and 
collectors tnake a single queue at the matt box comer and arrive and leave the corner on 
first-in-first-out basis. 

We model this post office with five kinds of actors: customer actors, collector 
actors, the door actor, the counter section actor, and the mail box corner actor. [See Figure 
8.1] The movement of customers and collectors is modelled as message-passing where 
messages are customer and collector actors and targets are the door actor, the counter section 
actor and the mail box corner actor. Components of the office, collectors and customers 



Fig. 8.1 



c ustomer s , co 1 1 eeto r s 




counter section 



mail box corner 



have their own local time. Thus, arrivals of customers and collectors at these components 
are in general mutually independent. Furthermore, we assume that the walking speed of 
customers and collectors may vary from person to person. So, for example, a customer 
arriving at the door after another customer may arrive at the counter section before him. 
This corresponds to the fact that the actor model of computation assumes nothing about the 
duration of message-passing except its finiteness. Besides such concurrent events, services 
at different counters are carried out concurrently, and of course depositing and collecting 
the mail in the mail box corner takes place independently of the activities at the counter 
section. 

In the subsections that follow, formal specif ications of the behavior of each actor 
will be given and we will state the task specifications that describe the overall properties 
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and effects that are created by the interaction and individual behavior of the component 
actors. 



8.1.2 Interactions at the Door 

To formally describe the activities in the, post office, first we need to define the 
states of actors in the model. 

For a customer, there are two internal factors which determine his behavior: the 
letters he carries and the number of stamps he needs at a given time. Thus we express the 
states of a customer actor by conceptual representations of the following form. 

(CUSTOM EH fallen: {...}) (r-*t<xmp*-m«*d«d: T» 

For a collector, the effects of interactions with other actors are expressed by the collected 
mail. So the state of a collector actor is expressed by conceptual representations of the 
following form. 

{COU.ECTOR {collected-mail: {...})) 

We cannot define the state of the post office as a whole in terms of the states of its 
components, because people can be in transit between the components. Customers and 
collectors may be constantly entering and exiting through the door while other customers 
and collectors may be changing the states of the mail box corner by depositing and 
removing the mail. Only the local states of the component actors are well defined. 
However, we can use the state of the door actor to describe useful aspects of the state of the 
whole post office if it is defined as below. 

The state of the door actor must be defined as an equivalence class of histories of 
message sent to it. The informal description of the model tells us that customers and 
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collectors arrive at the door when they enter and exit from the post office. So we assume 
that the door actor accepts four kinds of messages: 

(customer-entering: <customer>), (cuHomer-cxiling: <customer>), 

(collector-entering: <collector>), and (collector-exiting: <collector>). 
Thus the states of the door actor are defined in terms of these kinds of messages. Since the 
states of customer and collector actors are well defined at the time they arrive at the door 
actor, their states can be used to define the state of the door actor. This means that the 
information available in conceptual representations for customer and collector actors can be 
used. 

We define the state of the door actor at the time of message arrival by 

(1) the set of all customers inside the post office, 

(2) the set of all collectors inside the post office and 

(3) the set of all mail inside the post office. 

These three sets are sufficient to characterize useful aspects of the state of the post office as 
a whole and yet well defined as information local to the door actor, because, for example, 
the set of mail inside the post office is determined by the difference between letters brought 
in and letters taken out through the door by customers and collectors. We express the states 
of the door actor by conceptual representations of the following form. The key word, 
POST-OFF ICK, reflects the intention that they serve as the states of the whole post office. 

(POST-OFFICE (mail: {...})(cu$tomcn: {...})(collecior$: {...}))) 

A formal specification of the effects of interactions between the door actor and 
customer and collector actors is depicted in Figure 8.2. One should note the 
<couscd-evcnt:...> clauses: After a customer actor arrives at the door actor, a message 
(go-to-countcr-scction-if-necc*Mry:) instructs him to decide where to go next. Other 
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Fig. 8.2. A Specification of Interaction* at the Door 

<cvcnt: fl" the-door <= (customer-entering: C)] (sp-1) 

<prc-cond: 

( the-d oor is-a (POST-OFFICE (mail: {lm))(cu»tomers: {!cs})(coifector«: {»cls}))) 

(C £*-« (CUSTOMER (letters: {!I}K#-o/-*lampj-iwe«W: N))) > 
<nrxt-cond: 

( the-door is-a (POST-OFFICE (mail: {«m \\\)(customers: {|ct C}){ci>M«cl©r« {!cl«})» 

(C is-a (CUSTOMER (letters: {\\))(t-of-tt am pt- needed: N)j) > 
<caused-evcnt: |[C <= (go-to-couRter-section-if-meeestary:)'J » 

<<wcnt: B* the-door <= (rujilomcr-crutng: CI] (sp-2) 

<pre-cond: 

( the-door iV« (POST-OFFICE (mail: { «ml !l !m2})(cu*lomm-*: {{csl C !cs2})(ee// elor«: {!cls}))) 

(C *«-» (CUSTOMER (letters: {l\\)(0-of-stamps-needed: N)» > 
<ih».vi-coii</: 

( the-door iVn (POST-OFFICE (mail: {»ml »m2})(cu*<omer* {leal lct2})(collectort: {!ds})» 

(C i«-n (CUSTOMER (letters: {Vm*-ef-«amps-needed: N))) > 
^auMuf-ffwnf: If street <= C] » 

<*»ivni: IT the-door <= (coffoctor-flnterini': CL)] (sp-3) 

<l>re-cnttd: 

( the-door is-a (POST-OFFICE (mail: {lm])(customer$: {!cs})(co//cctor* ilclt}))) 

(CL is-a (COLLECTOR (collected-mail: {!cm}))) > 
<hexl-cnnd: 

( the-door is-a (POST-OFFICE (mail: {!m Um))(euMU>mers: {!cs}Xcoiiec<er*: {!cl« CL}})) 

(CL ix-o (COLLECTOR (rollected-mail: {«cm}))) > 
<cansed-event: j" mail-box-comer <g (collcctorr. CL)*| » 

<<!t>rni: |[ the-door <= (co/ientor-ftvttinjr: CL)] (sp-4) 

Kpre-cond: 

( the-door iV« (POST-OFFICE (mail: {"ml !cm !Ki2})(eu*iomer<: { let} )(co//cc lor*: {fclsl CL »c!2}))) 

(CL i.«-« (COLLECTOR (collected-mail: {!em}))) > 
<n*»rl-rim*/: 

( the-door i*-« (POST-OFFICE (mail: {|ml Im2})(ciujomer«: {«ci})(co//ecJor*: {"clsl !els2}))> 

(CL i*-« {COLLECTOR (rollcried-mail: {!cmj))) > 
<r«u*rrf-rt>*»it»: £ street <= CL] » 
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<cau$cd-cvcm:...> clauses indicate where a customer or collector actor is sent after it arrives at 
the door. In particular, customers and collectors are sent to the street actor after they exit 
from the post office. 



8.1.3 Interactions at the Counter Section 

Upon entering the post office, a customer must decide where he should go, i.e. to 
the counter section or the mail box corner. The decision is made in response to a message 
(pro-to-countcr-scction-if-ncccssary.), according to whether or not he needs stamps. This 
behavior of the customer is expressed by the following event specification. 

<event: |[C <= (go-to-countcr-section-if-necessary:)^ (sp-5) 

(Case- 1: 
<pre-cond: 

(C is-a {CUSTOMER (letters: {l\})(*-of-*tamp*-needed: N))) 
(N > 0) > 
<ncxt-cond: (C is-a (CUSTOMER (letter*: {U))(*-of-stamps-needed: N)))> 
<cau.tcd-event: P" counter-section <= (customer: C)J » 
(Cnsc-2: 

<pre-cond: (C is-a (CUSTOMER (letters: {l\})(*-of-stamps-ncedcd: 0») > 
<ncxi-cond: (C is-a (CUSTOMER (letters: {\\})(*-of-*lamps-nceded: 0)))> 
icaused-cvent: IT mail-box-corner <= (customer: C)]| »> 

Two points should be made about the specification above. First, the customer C sends 
himself to the counter section or the mail box corner. Second, the customer C does not 
change his state as described in the <next-cond:...> clauses. 

The effects of interaction between customers and the counter section are described 
by the following simple event specification. 
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<ci<cnt: IT counter-section <= (customer: C)1 {sp-6) 

iprc-cond: (C it-a (CUSTOMER (letters: {l\})(*-of-ttampi-nccdcd: N))) > 
<iwxl-cond: (C is-a (CUSTOMER (teller* {V})(*-of-$tamp»-needed: 0))) > 
<caused-cv<mt: |[C <= (go-to-mail-box-eortter-if-neeettary:)^ » 

This specification might look too simple. Of course, by using conceptual representations 

for the counter section which include more detailed information, we could express various 

activities and interactions such as customers waiting in a queue, and buying stamps at a 

counter. Also, we could define the state of the counter section in a way similar to that in 

which we defined the sates of the door actor. But for our present purpose, the event 

specification above is sufficient. 

When a customer leaves the counter section, he must again decide where to go 

next, the mail box corner or the door. The decision is made in response to a message 

(go-to- mnil-hox-if-ncce*$ary:), according to whether or not he is carrying letters. This is 

expressed as follows. 

<i**><?nf: |[C <= (fio-to-mail-box-cornor-if-neceuary:)^ (sp-7) 

</>rr-cond: 

(C i*-a (CUSTOMER (letters: \\\))(9-of-«amp*-needed: N») 

<twxt-ctMtd: (C U-a (CUSTOMER (Irtterx \l\}){*-of-itampi-need«d: N))) > 
<caus<!d-ev<!nt: [ mail-box-comer <g (cuttomeri Cfl >) 
(Ca*r.-2: 

</)r«-rond: (C i*-a (CUSTOMER fatten: {))(*-of-itamps-needcd: N))) > 
<n«xi-cond: (C i*-a (CUSTOMER (leitern {))(*-of-sto,mp*-needed: N») > 
<c.au*cd-event: [the^door <s (customer-exiting: C)(l »> 

Note that no conditions are made for the number of stamps needed N in the 
preconditions in the above specification. [See, Section 8X5.3 
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8.1.4 Interaction at the Mail Box Comer 

To complete the local specifications, we must specify the interaction between the 
mail box corner and its users. An important fact stated in the informal description of the 
model is that customers and collectors wait in the same queue before the mail box and that 
they deposit or collect mail on a first-in-first-out basis. This fact allows us to define the 
state of the mail box corner by the set of letters brought by the customers who arrived at 
the mail box coiner after the collector who arrived most recently. Letters brought do not 
necessarily mean letters that are already put in the mail box. They may still be carried by 
customers in the waiting queue. We use conceptual representations of the following form 
for the mail box corner. {MAIL-BOX-CORNER {posted-mail: {...})) The interaction is 
described by the event specifications in Figure 8.3. 



Fig. 8.3. A Specification of the Interactions at the Mail Box Corner 

<«vent: IT mail-box-corner <= {customer: C)]] (sp-8) 

<prc-cond: 

( mail-box-corner is-a {MAIL-BOX-CORNER {potted-mail: {Jm}))) 
(C is-a {CUSTOMER {letters: \\\}){*-of- stamps-needed: N))) > 

<ncxl-cond: 

( mail-box-corner is-a {MAIL-BOX-CORNER {potted-mail: {«m «l})» 
(C is-a {CUSTOMER {letters: {}){*-of-*tamps-nccdcd: N))) > 

Kcauscd-evoiii: H" the-door <= {customer-exiling: C)]j » 

<event: [[ mail-box-corner <= {collectors: CL)J (sp-9) 

<pre-cond: 

( mail -box-corner is-a {MAI I -BOX-CORNER {posted-mail: {!m}))) 

(CL is-a {COLLECTOR {collected- mail: {!cm}))) > 
<next-cond: 

( mail-box-corner is-a {MAIL-BOX-CORNER {posted-mail: {}))) 

(CL is-a {COLLECTOR {collected-mail: {!cm !m})» > 
<causcd-cvcnt: IT the-door <= {collector-exiling: CL)]) » 



- 190 - 

8.1.5 Assumptions of No Implicit Interactions 

In addition to the above specifications of local interactions, we must make the 
following assumptions of global nature to describe the post office model completely. 

Assumption -I 

Customer and collector actors do not receive any messages except those explicitly 
stated in the event specifications sp-1 to sp-9. 

Assumption-II 

The counter section actor and the mail box corner actor interact with only the 
customer and collector actors which have entered through the door. The door 
actor interacts with only the ieuiiomer-extiUig:...) and {fiollector-exiting:...) messages 
which contain collector or customer actors which have entered through the door. 
(No customer or collector actor can arrive directly at these actors without going 
through the door.) 

The first assumption implies that customer or collector actors do not change their states 
immediately after an event E until the event caused by E, where E is one of the events 
specified by sp-1 to sp-9. For example, immediately after the event 

IT counter-section <= (cuuomcr: C)]|. the state of a customer C which is stated in the 
<nrxt-ronrl:...> clause of the event specification sp-6 do not change until C receives the 
ifcn-to-mail-hox-comer...) message. Thus, in the events specification sp-7, the number N of 
stamps needed (by the customer C) is zero, because it was zero immediately after 
g" counter-section <= {r.u*tom*r: C)]| as stated in the <next-cond:...> clause of sp-6. 
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8.2 Task Specifications 

We have specified the individual behavior and mutual interaction of actors in the 
post office model. These specifications are local in nature. In this section, we will state 
some of the overall [global] task specifications of the post office that should be implied by 
the local specifications. It is important that such task specifications be stated in terms of 
externally visible actors because the function of the post office should be specified and 
understood without knowledge of the details of what is going on inside. These actors are 
the door actor, and customer and collector actors which are outside the post office. 

Four task specifications of the post office are in order. For each task specification, 
an informal statement is followed by the formal one. 

The first task specification is expressed in terms of a customer's two states: one 
before he enters the post office and one after he exits. This may be considered as a 
specification of the function of the post office from the view point of a customer. 

Task-I (Customer is Guaranteed to Return without Letters) 

If a customer visits the post office, he must eventually leave there. When he leaves the 
post office, he must not be carrying letters and he does not need stamps. 

<evcnt: fl* the -door <= {customer-entering: C)]J 

<prc-cond: (C is-a {CUSTOMER {letters: {V}){*-of-stamps-needcd: N))) > 

<caused-evcnt: If street <= Cj > 

<post-cond: (C is-a {CUSTOMER {letters: {}){*-of-stampt-ncedod: 0))) » 

The second task specification is the collector version of the first one 
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Task-Il (Collector is Guaranteed Not to Lose Any Mail) 

If a collector visits the post office, he must eventually leave there. When he leaves the 
post office, he must be carrying the newly collected mail [which may be empty] in addition 
to the mail he brought into the post office. 

<event: fl" the -door <= [collector-entering: CL)]] 

<,jre-cond: (CL is-a {COLLECTOR (collected-mail: {!cml}))) > 

<c.av,sed-cvent: If street <= CL )]] > 

<po*t-cond: (CL is-a (COLLECTOR (collected-mail: {..Jcml...}))) » 

The next task specification is expressed in terms of the interaction between 
customers and collectors through a set of letters. This may be considered as a specification 
of the function of the post office from the view point of individual letters. 

Task-Ill (Guaranteed Collection of Mail) 

Suppose that a set {'m} of letters is brought into the post office by a customer C. 
Then if there is a collector CL who enters the post office after the customer C leaves, 
then there always exists a collector CLL (who may be the collector CL) who brings the set 
{!m} of letters out of the post office to the street. 

For an event E c _ en j er = I Prte-door <= (customer-entering: C)]J 

where (C ix-a (CUSTOMER (lcitcr»:{lm})(*-of-ttamp$-needed: N))), 
if there exists an event E c) _ en j er = If the-door <a (collector-entering: CL)]1 
such that E c . enter -act-> E cl _ enUr -Brr->, he . door E e . exit 

where E c _ ex jt = If the-door <= (customer-exiting: C)J, 
then there must exist an event E c ||- S t ree t = [street <= CLLj 

such that (CLL i»-a (COLLECTOR (collected- mail: {..Jm...}))). 

It should be noted that the mail of a customer C could be collected even if no collector 
enters the post office before C leaves. But in this case there must be some collector which 
arrives at the mail box corner after C arrives there. (Of course. this cannot be stated in the 
task specification because the mail box corner which is an internal component of the post 
office should not be mentioned in the task specifications.) 
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The next task specification is expressed in terms of the states of the-door (more 
precisely, sets of mail inside the post office) at different times. This task specification is 
derived from Task-Ill. 

Task-lV (No Stagnation of Mail) 

Let UM, UC and UCL respectively be the set of letters, the set of customers, and the set 
of collectors inside the post office in a given situation S. If there is a collector CI who 
enters the post office after all the customers UC and all the collectors UCL (who were 
inside the post office in the situation S) leave the post office, the set of letters which are 
inside the post office after the collector CL leaves does not share any letters with the set UM 
of letters (that were inside the post office in the situation S). 

Suppose that 

( the-door »- a {POST-OFFICE {mail: {*m}){cu»tomcrM: {lcs)){collcctors: {!cls}))) holds 
in S = Sirf!" the-door <= Mj]. 
If there exists an event E = IT the-door <= {collector-entering: CDj 
such that 
for any customer Cj in {"csj and any collector CLj in {!cls}, 
the following ordering relations hold 

E cj - arr ->the-door E and E clj -« rr ->the-ck>or E 
where E c . = I the-door <= {customer-exiting: Cj)]] 

E c |. = IT the-door <= {collector-existing: CL:)J, 

then for any event EE = j the-door <= MUj 

such that E -arr-> |he . d00r E' -arr->, he . door EE or E' = EE 
where E' = I the-door <= {collector-exiting: CL)J, 
it is the case that 

( the-door is-a {POST-OfFICE {mail: {!mm} ){cuttomer$: {...}){collector»: {...}))) holds 
in 5tr[EE] where {!m} fl {!mm} = 4> 
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8,3 Verification for the Task Specifications 

In this section we will demonstrate that the event specifications, which are given in 
Sect 8.1 as the description of the behavior of individual actors in the model and their 
interaction, satisfy the task specifications in the previous section, Also, some of the 
interesting properties of the event specifications given in Section 8.1 Will be revealed in the 
course of the verification. 

8.3.1 Verification for Customer's Guaranteed Return without Letters 

First we will verify the following task specification. Some of the properties 
observed in the process of the verification will be used later in the verification for other 
task specifications. 

TaskJ. (Customer's Guaranteed Return without Letters) 
<fft'«»iu: (T the-door <= (cuHomar-enterittg: 6f| 

<prc-cond: (C is-* (CUSTOMER (letiert: {V]){^cf-Mampt-Meded: N))> > 

<ctiu*i> d-nwnt: [street <■ C J ■ > . 

<po.u -cond: (C U-a (CUSTOMER {IclHrt: {))(s-of-ttampt-nccded: 0))) » 

(Verification) This task specification is established by tracing sequences of events which 
involve a customer actor. Such sequences are obtained by checking ; causal relations among 
events described by the event specifications givenWSect 8.1. tracing such a sequence can 
be done by examining (local) states of actors parUcjpaUng in each event, but certain 
cautions are necessary in dealing with the state of th»-door actor which represents external 
state of the whole post office. Furthermore, it should be noted in the following 
demonstration that the reasoning from one event to another crucially depends on 
Assumption-I in Section 8.1.5. Namely, we assume that the state of a customer C does not 
change from. an event E to the next event caused by E. Below this assumption will be used 
without being mentioned. 

Fust we assume that an event E enter takes place as described below. 
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E enter Qhe-door <= {cuuomcr-entfring; r.)J 

where (C ha {CUSTOMER fatten: {iA)){*-of-stnmp*med*d: N))) 

(the-door h-g {POST-OFF ICEAmm-. iltn)){cu,totner$: {!c«})(c«»//*rior,: {!cls}))) 

The event E entcr and the first assertion are assumed by the task specification to be 
verified, and the second assertion is assumed in the <pre-cond:..> clause in the event 
specification sp-I. Note that as sp-1 specif ies, the state of th«-door immediately after this 
event is expressed as 

( the-door ha {POST-OFFICE {,nail: {|m IWevUomers: {«« CJMebf totem {lets}))) 
which means that the customer C is now inside the post of f ice. The <cau»cd-*v*M: ..> and 
<nrxt-cond:...> clauses of sp-J tell us what will happen to C next and what state C will be in. 

E decision-l : C c <= ^KO-to-coanier-tnction-if-ncceuary:)']^ 

where (C h-a {CUSTOMER {letter* {\\)){*-of-dt*mp$-needed: N))) 

To know what event will take place after E dcciskm _,, the event specification sp-5 is referred 
to. Two cases need to be considered. (1) E^^ is caused if N > and (2) E mai ,. box is 
caused if N = 0. 

E counter IC counter-section <« Icuitomar: C)J 

where (C iV« {CUSTOMER {letters: {\\}){*-of-$tamp>-needed: N)», (N > 0). 

The event specification sp-6 tells that the following event E decision _ 2 is caused by E coumer 
and that the number of stamps needed becomes zero. 

decision-2 : C^ <= ^K°~ to ~ j nnil-hox-eomer-iS-neceuary:)'^ 

where (C h-a {CUSTOMER {letters: {V}){»-0f-stamps-needed: 0))) 

To know what event will take place next, the event specification sp-7 is referred to. We 
need a case analysis: (I) E mai| . box is caused if I * {} and (2) E fixit is caused if I = {}. 

E mail-box : F mail-box-conwr <= lc.u.»it>m*n CI] 

where (C h-a {CUSTOMER {letters: W}){*-of-stam P M-needed: 0))) 

Note that E^,.^ is also caused by E ded$ion ., as well as E dedsion _ 2 . Both E decision _, 
and E decision-2 ,nsure that the number of stamps needed is zero. On the other hand, the 
letters {•)} the customer C is carrying may or may not be empty, because E dedsion _ 2 insures 
that I is not empty, but E ded5io|H does not. The event specification sp-8 tells us the next 
event E exit . 
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E exit : IT ^e-door <s (rmtowtor-wriiing.-C)] 

where (C i*-a (CUSTOM HR UotterK {\)(»-of-uampt-noeded: N)» 

( the-door w-o (POST-OFFJCK (mail: {...}){«»« onwr* {jCIXeof lectors: {...}))) 

The first assertion is guaranteed by the <next-cot*i:.J clause of the event specification sp-8. 
The second assertion that the customer C is still inside the post office must hold in order 
for the event specification sp-2 to be applied. This assertion is guaranteed by the following 
facts: 

(1) Examining all the event specifications sp-1 through sp-9, events of the form 

IT the -door <= (customer-exiting: C)J are the only way for C to exit from the post office 
(i.e. to eliminate C from the (eusiom«r<r {„.}) component of the conceptual representation 
for the door actor). 

(2) An event of the form IT the-door <s (cuitomer-exiting: CJJ have not taken place since 
C entered the post office. 

Now the event specification sp-2 insures the following event E^reet wi " na PP en and tne 

assertion wilt hold. 

E street IT street <= Cl 

where (C i*-a (CUSTOMER (letters: {)H*-t>f-ttamp t -ne<>ded: 0))) 



follows 



The causal relations among the events E^,^ through E^,^ are illustrated as 



E enter ~" > E decision-l '"* E mail-box ""* E exit * * E street 

! 

E counter * E decis l ion-2 

Since all the event specifications used in the above discussion guarantee that the events 
given in their <cauMd-event:...> clauses always take place, Ej^^ is guaranteed to take place. 
And the state of the customer C in the situation E street is exactly what is required by the 
task specification. (End of Verification) 



The second task specification given in the previous section can be verified in the 
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same way as above. In fact, applications of the event specifications sp-3, sp-9 and sp-4 in 
this- order will do. It should be noted that in using the event specification sp-4, a 
justification similar to the one we made, in the reasoning from E^j to E street , for 
applying the event specification sp-2 is necessary. 



8.3.2 Verification for Guaranteed Collect ion of Mail 

Task-Ill (Guaranteed Collection of Mail) 

For an event E c . ent0r s If tho-door <= (cuxtomer-cntering: C)J 

where (C i*-a (CUSTOMER Uetteru[lml)(*^?*tom 4 *meeded:im, 
if there exists an event E e |_ 6nter - IT the-door <= (collector-entering: CL)]] 
such that E^j.,. -«t-> E c ^ xH — >H*-door Ed-«t«r 
where E c . axit = If the-door <a (customer-exiting: C)J, 
then there must exist an event E af str— i <« CLlJ 

such that (CLL u-a {COLLECTOR (collected-mail: Mm...}))) holds. 

To verify this task specification, we rely on the following lemma which is easily 
derived from the event specifications given in Sect 8.1. This lemma guarantees that if a 
customer enters the post office carrying a set {!!} of letters, he always arrives at the mail 
box corner carrying the same set of mail. 

Lemma 

For an event E c . en ^ er = [T th«-door <= (customer-entering: C)J 

where (C t*-« {CUSTOMER {letter*: {\\})(*-of- Ham pt- needed: ?))), 
there always exists an event E e . mBiJ . box = f nrnil-box-cornT <= (customer: C)J 
wtiere (C it-a i£USTOMER {letters: {l\})(*-of-itam P i-ne<,Jcd: ?))) 
such that E c . enJ-r -*t-> E,.^,.^ 

This was justified during the verification of the first task specification. 
[Note that E enter — > E ma j|-box in the demonstration of Task-!.] 
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(Verification of Task-Ill) 

Suppose that an event Ec-^^. s f thf-doo r <■ (cuttomer-entering: C)]| takes place 
where 

(C it-a (CUSTOMER (lettert: [\\}){»-oHtampt-needed: ?))) 
holds. By the above lemma, an event Ee-n^f-box *- F m>iH>ox-corft*r <* (cuttomcr: C)]J 
always takes place and the same assertion 

(C it-a (CUSTOMER {letter*: {H))(g-of-tlampi-needed: ?))) 
still holds. Here we assume that the following assertion holds when E e _ mi jj_ box takes place. 

( mail-box-corner it-a (M/HL-ROX-C0RNRR (potted-mail: {!pm}))). 
Then, by the event specification sp-8, the assertion 

( mail-box-corner it-a (MAIL-BOX-CORNER {potted-mail: {Ipm !!}))) 
holds immediately after E^.^.^ and omil the next message arrival at the 
mail-box-corner. Sp-8 also guarantees that E c _. x jt « T the-door <* (euttomer-exiting: C)J will 
take place. 

Then suppose that the following event takes place after ^ CTltri \\ 
E c1-enter *^ ' ttf*<J<fof" '<* (eottejkor-emeriiigf t3.)J 
where (CL is-a (COLLECTOR (polleeted-mailt {»«ntf)) Holds. By the event specification sp-3, 

E cl-iTuH-box s r Mail-bbx^orner ' <* (eollectort: CL)J 
takes place where (CL i»-a [COLLECTOR {collected-maiL {tcmJW) still holds. At this point, 
the ordering of the events which have already occurred is expressed as follows. 

E c-enter "**"> E c-ro«l-oox "•**"> E c-ex» fcirr ^hinloor ^chwlir "• et " > E cl-m«l-box 

The important fact here is that E c - ma j|-| BOX precedes E e |- ma y-bor We shall consider two 

cases: 

Case-1: If any collectors do not arrive at the mail box corner, between Ej-maj^bo* **^ 

^l-mail-box 1 the state of the mail D0X corner, at the time of E^,,,^.^, is expressed as 

( mail-box-corner i*-a (MAU^BOX-QDRNER (potiod-maU: („Jpm„.!l-.J))) 
because customers arriving between E £ f ~ _» ^ aad E^mim j^ ™*ty deposit, but never 
collect mail. Then as the event specification sp-9 states, the collector CL collects aU the mail 
{...!pm.„!l...} and then go to the door. 

Case-2: If there are collectors who arrive at the mail box corner between E e . |na j|. box and 
E d-mail-box- then the ^' rst one among such collectors will collect the mail which includes {11} 
and {!pm} and then go to the door. 



- 199 - 

In both cases, some collector carrying {■!}, say CLL, arrives at the door from the 
mail box. To insure that the collector CLL goes out to the street, the two assertions given in 
the </)re-cond:...> clause of the event specification sp-4 must be satisfied. One assertion says 
that CLL must be one of the collectors who appear in the conceptual representation of the 
door actor at the time CLL arrives, namely, the following must hold. 

( the-door is-a (POST-OFFICE (mail:{...})(cu»tomer*:{...))(collfictor*:{...ClL...}))). 
Assumption-11 in Section 8.1.5 guarantees that this assertion holds, because it assumes that 
all the collectors arriving at the door from the mail box corner must have entered through 
the door, so by sp-3 CLL must appear in the (collectors:...) component of the conceptual 
representation of the door. This completes the verification. Note that Assumption-I was 
used throughout the above demonstration. (End of Verification) 

The last task specification "No Stagnation of Mail" can be verified by using 
already established task specifications. As was done in this task specification, let us suppose 
that the state of the post office is expressed by the following assertion. 

( the-door is-a (POST-OFFICE (mail: {lm})(cuitomen: {lcs})(collector*: {'els}))) 
Then it is the case that every letter 1 which is an element of the mail {!m} inside the post 
office is brought in either by a customer or by a collector. If I is brought in by a customer, 
we can use the third task specification which has been just established above. If I is 
brought in by a collector, the second task specification "Collector is Guaranteed Not to Lose 
Any Mail" insures that I will be brought out by the same collector that brought I into the 
post office. So both cases are proved. 
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Q. Conclusions and Future Research 



In this thesis, we have presented the local state approach to specification and 
verification techniques for both serial and parallel computations. As stated in the 
Introduction (Chapter 1), the work reported here has made four major technical 
contributions. In concluding the thesis, we would like to first review these contributions 
and then discuss their implications in the light of our projections for future research. 
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9. 1 Summary and Conclusions 

As was demonstrated in Chapters 4 and 6, the local state approach provides 
powerful and convenient specification techniques for abstract data types with parallelism 
and side-effects with which previous techniques had failed to deal. 

As the post office model in Chapter 8 illustrates, specification techniques based on 
local states enable us to describe the complex internal concurrent activities of a system, such 
as an operating system or a multi-user data base system, in terms of the individual behavior 
of its subsystems and their mutual interaction. In order to express the overall functional 
behavior of such systems (task specifications), the use of local state* turns out to be not only 
useful, but crucial. In addition, however, We sometimes need to state temporal ordering 
constraints among events that are difficult to express in terms of the state changes of 
individual subsystems. For this purpose we have used an event-oriented specification 
language[Greif-Hewitt75, Hewitt-Baker77] in which the ordering concepts in the underlying 
computation model can be talked about directly. Thus, with the complementary use of the 
ordering constraint statements, the effectiveness and versatility of the local state approach 
in specifying the behavior of systems with high internal concurrency is strengthened. 

To describe the states of individual data and procedural objects, we have 
developed a system of notation called conceptual representations. Based on this notational 
device, we have presented a formalism for specification arid verification. As was seen 
throughout the thesis, this formalism allows us to express states of individual objects 
directly and explicitly. Thus we believe that specifications written in our formalism are 
easy to understand and are less error-prone in their completeness And consistency, as 
compared with those written in other formalisms, Moreover, the separation of the states of 
an object from its identity makes it possible for conceptual representations to express 
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sharing structures among objects and multiple instances of a class of objects. 

The ability of our formalism to express sharing structures and multiple class 
instantiation enabled us to develop a method for symbolic evaluation of programs written 
in object-oriented languages, which has not been attempted before. The developed method 
is used for verification of serial computations arid has suggested an approach to mechanical 
program analysis (Section 5.4, Chapter 5). 



9.2 Future Research 

We have defined the states of an individual object (actor) as equivalence classes on 
the past histories of messages (operations) sent to the object. Local states thus defined are 
expressed by conceptual representations which mathematically comprise sequences, 
collections and tuples. On the other hand, the state of an object can be identified with a 
mathematical function which is obtained as a solution of the behavioral equations 
introduced in Section M, Chapter 6. So far the relationships between the above two 
interpretations of states have not been made clear. We foresee that the investigation of 
these relations will reveal very rich mathernatical structures and that, consequently, the 
properties of implementation invariajUs (Section 5.34, Chapter 5) which we have left 
informal will be understood precisely. 

The techniques exemplified by the model of a simple post office can be applied to 
the specification and verification of various distributed information processing systems. 
Furthermore, the techniques used in this thesis have a direct application in the area of 
business automation. We expect that actor-like procedural objects will enormously increase 
the flexibility and security of message and document systems by replacing "paper" forms 



-203- 

and letters and "paper" documents with "active" (procedural) counterparts that are sent to 
work stations in computer networks. Moreover, we can apply our techniques to the 
specification and verification of object-oriented simulation and system description 
languages such as the DELTA system[Holbaek-Hassen-et-al771 

The verification process for parallel computations described in this thesis is 
informal. The formalization of such a process is desirable. For this purpose, a formal 
specification language in which both local states of objects and ordering constraints of 
events can be expressed in a coherent fashion must be developed, together with sound and 
powerful inference rules which are effective in dealing with the partial ordering of events. 
With such a formal system available, we will be able to construct practically useful software 
tools which assist us in the construction of parallel programs and distributed message 
pacing systems. Various important properties, such as no-deadlock, no-starvation, and the 
property that a system meets its specifications, wiU be mechanically analyzed with such 
software tools. 
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Appendix I - Derivation of Axiom (5) 

The following axiom which was given in the algebraic specification of queues in 
Figure 2.6, Chapter 2. 

Axiom (5) 

if -iIS-EMPTY(Q) a DEQUEUED, A) * <B, Q*> 

then DEQUEUE(ENQUEUE(Q, A)) = <B, ENQUEUE(Q', A)> 

This is derived from the following specification of queues based on conceptual 
representations [which is identical to the one given in Figure 2.2, Chapter 2, except that the 
functionality of the operations is omitted! 

(El) CREATE-QUEUEO > (QUEUE []) 

(E2) ENQUEUE{{QUEUE [!x]), A) > {QUEUE [U A]) 

(E3) DEQUEUE{{QUEUE [])) > ERROR 

<E4) DEQUEUE^*;*/!? [A !x]» > <A , {QUEUE [!x])> 

(E5) IS-EMPTY«(H/fi(/E [])) > TRUE 

(E6) l$-EMPVf{{QUEUE [A !x]» > FALSE 

(Derivation) 

(1) -.IS-EMPTY(Q) given as the premise of the axiom. 

(2) DEQUEUE(Q) = <B, Q'> given as the premise of the axiom. 

From (1) and (E6), Q must be of the form 

{QUEUE [front-alanwnt {rut]) 
From (2) and (£4), front-«l«ment ■ B and Q' contains [frett]. Thus (3) and <4) 
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hold. 

(3) Q = {QUEUE [B !r«t]) 

(4) Q' = (QUEUE [!r«st]) 

(5) DEQUEUE(ENQUEUE(Q, A)) given in the consequence of the axiom. 
= DEQUEUE<ENQUEUE«(U/f;(/f; [B !r««t]), A) ;f rom (3). 
= DEQUEUEUQU EUE [B !r«st A])) ; from (E2). 
= <B, (QUEUE ["rest A]))> ;from <E4). 
= <B, ENQUEUEUQUEUE [Irest]), A)> ; from (E2). 
= <B, ENQUEUE(Q\ A)> ; from (4). 

Hence, DEQUEUE(ENQUEUE(Q, A)) - <B, ENQUEUE(Q\ A» (End of Derivation) 
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Appendix II - Limits of Algebraic Specification 

To show the existence of abstract data types which cannot be expressed by a finite 
set of axioms in the algebraic approach, M. £. Ma jster[1977] gave a stack type which allows 
us to look at any stack elements by using a position information i. The functionality of this 
type is as follows. 

CREATE: —> stack .creates an empty stack. 

PUSH: stack X item —> stack or error 

;tries to insert an item at the top. 

;if i is not pointing to the top, undefined 

[otherwise i points to the new top item. 

DOWN: stack — > stack or error 

;tries to increment i by one. 

;if i already points to the bottom item, error. 

POP: stack — > stack or error 

[tries to remove the top item. 

;if i is not pointing to the top, error 

[Otherwise, i points to the new top item. 

READ: stack — > stack or error 

;tries to read the item pointed by i. 
;if stack is empty, error. 

RETURN: stack — > stack or error 

;tries to cause i to point to the top item. 
;if stack is empty, error. 
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Unfortunately, the axioms for these operations cannot be characterized finitely. 
For example, we need infinitely many axioms expressed as follows. 

RETURN(DOWN) m (PUSH) n (i lf ...,i n ) * (PUSH)"^ i„) 

for all m > and m < n 

where PUSH n (i 1( ... f i n ) = PUSH(...PUSH(CREATEO, 4)..., i ft ) 

This data type can be easily specified by using conceptual representations of the 
following form. 

ISTACKipotition: \){itcmt: [...))) 

The (position:...) component keeps the position information and the conceptual sequence in 
the (items:...) represents stack elements. A specification based on the conceptual 
representations is given below. 

(1) CREATED — > (ST/lCK(po*ilion: l){itom,: [])) 

(2) PUSH((ST/lCK(position: Mitcmx: [is])), I) 

if i = 1 — > (STACK(potition: \){ilcmt: [I >s]» 
otherwise — > ERROR 

(3) D0WN((6T/1CK (position: i)(ilcm«: [U])) 

if\ < length[!s] — > (ST/\CK(pouiion: i + l)(iiemt: [!$])) 
otherwise — > ERROR 
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(4) POP ({STACK position: Mitcmx: [!s])) 

if i = 1 and s = [I Jrest] — > (STACKipontion: \){itemt: ['rest])) 

otherwise ---> ERROR 

(5) READ((y/7]CK(/>oMiioii: ?)(i«?mj<: [])) — > K/JKOK 

(6) READ((S77ICK(/>o«iioM: \){item*: [«xl I «x2])) — > I 

w/ifre length[!xl] = i - 1 

(7) RETURN((S771CK(juo«iion: i)(itcm*: [«s])) 

'/ s = [] — > KRROR 

otherwise — > (STACKiposition: IHitemj.- [!s])) 
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Appendix II! - Recursion, Iteration and Loop Invariants 

The handling of recursive invocations of modules in symbolic evaluation has been 
illustrated in the example of empty-one-queue-into-anoth«r in Section 5.2.1, Chapter 5. In 
general, recursive invocations are treated as the same as ordinary invocations of modules. 
When a [recursive] invocation of a module M is encountered in symbolic evaluation, the 
contract of M is referred to and the specified results and postconditions are used to 
continue the symbolic evaluation after making sure that all the preconditions of M are 
satisfied. 

Iterations in implementations can be handled almost in the same way, because the 
iteration construct in PLASMA allows us to treat an iteration as a module. Thus if 
specifications of such modules are supplied, loops can be treated as ordinary modules. 

Another way of dealing with iterations is to rely on assertions which hold every 
time the control reaches the beginning point of a loop. Such assertions are called loop 
invariants or inductive assertions[F\oy<16l, Hoare69]. Since loop invariants are usually not 
derived from the process of symbolic evaluation, they must be supplied externally. 
Symbolic evaluation of the part of a code which follows such assertions is carried out under 
the assumption that the assertions hold in the situation corresponding to the beginning 
point of the loop. To illustrate this technique, we will consider a simple example. 
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Fig. 1 1 I.I. An Iterative Version of empty-ono-queue-into-enother 

(empty-one-queue-into-another-a = 
(=> [=ql =q2] 
C[ql q2] => 

(loop s 
(5> [=qql =qq2] 
** 
(rules (qql <- (rf?:)) 
(s> {exhausted:) 

_ C _ 

exhausted-qql 

(done: [qql qq2])) 
(=> [sfroni-of-qql sdequeued-qql] 

_ c 

deque ued-qql 

(qq2 <= (nq: f ront-of-qql )) 

(loop <= [dequeoed-qql qq2])) )))))) 

In Figure IH.l, an iterative version of empty-one-queue-into-another-a is given. 
The loop invariant for loop which holds at the point where ** is placed in the code is 

[fxxl !xx2] « [|xl !x2] 

where xxl and xx2 are the elements of the impure queues which are bound to qql and qq2, 
respectively, and xl and x2 are the elements of the impure queue* bound to ql and q2, 
respectively. This invariant is expressed in our formalism as follows. 
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<Ioop- Invariant: ['xxl !xx2] s [Jxl 'x2] 
where 

in 5i?[[[[oo£<=[QQl QQ2]]]] 

(QQ1 «5-n [IMPURE-QUEUE [!xxl])) 
(QQ2 is-a {IMPURE-QUEUE [!xx2])), 

in St?[[[ empty-one-queue-into-another-a <s fQl 02Q] 

(Ql i.«-a {IMPURE-QUEUE [!xl])) 
(Q2 £*-« {IMPURE-QUEUE [!x2J» > 

Given the above invariant, it is easily demonstrated that the implementation in Figure III.l 
satisfies the contract for empty-one-queu«-into-anoth«r given in Figure 5.5 in Chapter 5. 
The key point of the demonstration is that when the control reaches S exhausted _ qql . the 
impure queue QQ1 that qql is bound to is empty, i.e. xxl = []. Therefore, the elements of 
the impure queue QQ2 that qq2 is bound to, which are expressed as xx2, are equal to [!xl 
!x2] because [Jxxl !xx2] * [!xl i x 2] (from the invariant), and xxl = [] imply xx2 = [!xl 
!x2]. The rest of the demonstration can be carried out almost in the same way as that for 
the recursive version shown in Section 5.2.1, Chapter 5. 
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Appendix IV - Convergence of empty-one-queue-into-enother 

Most event specifications written in our specification language contain 
<cnusrd-rvrni:..> or <r«iurn:...> clauses. As explained in Section 43.1, Chapter 4, the existence 
of these clauses in an event specification indicates that an event £ stated in such a clause is 
required to take place. Thus, to verify an implementation against specifications, we have to 
demonstrate that the event £ always takes place, as well as that the postconditions are 
satisfied. 

As an example, let us consider the convergence of the implementation of 
empty-one-queue-into-another [hereafter empty] given in Figure 5.5 in Chapter 5. [The 
following discussion is based on the symbolic evaluation of the implementation presented in 
Section 5.2.1, Chapter 5.] For the demonstration of the convergence, we need to show that 
the control always reaches the situation Sexhaustad-ql* provided that the two actors sent to 
empty are distinct and both are impure queue actors. 

If the impure queue bound to ql becomes empty during the recursive invocation of 
empty, S e xhausted-ql can De reacne d- Thus it is sufficient to show that the length of the 
impure queue eventually becomes zero. Since the length of the impure queue is an 
arbitrary non-negative integer when it arrives at empty for the first time, we need to show 
that its length decreases at its every subsequent arrival at empty. What has to be shown can 
be stated in our formalism as follows. 

( Icngi A-o/(ql) in S received-queue* * 

is-greatcr-than (*) 

( /cn*»A-o/(dequeue-ql) in S #nqu#u#d _^2 ) 

To show this, the situational tree produced by the symbolic evaluation of the 
implementation is examined. Leagth-of on impure queues is defined as 
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property. l<mgth-of(Q) s Isngth(x) 

where (Q is-a {IMPURE-QUEUE [!x])) > 

By using assertions about Ql and Q2 in conjunction with the binding information for ql 
and dequeued-ql, we obtain the following facts. 

lcn K lh-of(nl) s length(xl) in S rec .j v#d ^ u#u#$I 
/«ri/ri/i-o/(dequeu«-ql) » l«ngth(y) in S^^y,,^ 

Since xl = [B !y] holds, the desired relation (*) is shown. 

Note that the precondition that Ql and Q2 are distinct actors was used in obtaining 
the assertion about the state of Ql in S^mmn-qa- This precondition guarantees that |[Q2 
<= (nq-....)J does not change the state of Ql, and hence that assertion could be inherited 

f ,oni S dequeu«d-ql 
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Appendix V - Another Specification of Qne-a-at-Time Serialize™ 

Another specification of one-at-a-time serializes is given as the following four 
event specifications. The first event specification is concerned with the creation of a 
one-at-a-time serializer. The second one describes the event where the serializer receives a 
request. A buck passer actor BP is created and placed in the crowd. Note in {Case- 1:...) 
clause that BP is sent to the resource R as the continuation of the message in the caused 
event. A reply from the resource is always sent to a buck passer BP. This is described in 
the third event specification. Then the buck passer sends the reply from the resource to the 
serializer G which created BP. The fourth event specification describes how the reply sent 
from the buck passer is handled by a serializer. 



<nvcni: if create-one-at-a-time <= Rj 
(return: G* > 
<past-cand: (G is-a [ONE-AT-A-TIME [queue: [])[crou>d: {))insource: R))) » 

<cf«-m: |[G <== Mj 

u-.here M = [request: RQ reply-to: C] 
[Case- 1: 
< P re-eond: (G is-a [ONE-AT-A-TIME [queue: [))[erowd: {}){reu>urce: R))) > 
<nexi-cond: 
(G is-a [ONE-AT-A-TIME [queue: [])[erou>d: {BP*}){rc*ource: R))) 
(BP is-a [HUCK-PASSER [continuation: C)[serialixen G))) > 
<cavscd-et'ent*: |[R <== [request: RQ reply-to: BP]J >) 
[Case-2: 
<,,rc conJ: (G is-a [ONE- AT- ACTIVE [queue: [U)){crowd: {BP))[resource: R))) > 
<nrxt-ro,,d: (G is-a [ONE-AT-A-TIME {queue: [|x U]){erowdi {BP})(reu>urce: R)» > 
Kraused-events: {) >)> 
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<<?»;*»/.• [[BP <== [reply: A]J 

<pre-eond: (BP ix-a {BUCK-PASSER (continuation: C)(terialixer: G))) > 
<caused-eveht: |[G <== [rcp/y: (6uc*: A (continuation: C) (6uc*-pa*»«r; BP))]J» 

<cjwii: [[ G <== [r«?pfy: (6uci: A (continuation: C) (6uc&-paj«er: BP))]J 
(Case- 1: 
<l>rr-c.ond: (G tVa (ONE-AT-A-TIME (queue: [])(crowd: {BP})(r«jroure«: R))) > 
<n*xt-cond: (G is-a (ONE-AT-A-TIME (queue: [)Hcrotod: [))(resource: R») > 
<cauitcd-events: |[C <== [reply. A]J >) 
(Casc-2: 
<pre-cond: 
(G i5-o (ONE-AT-A-TIME (queue: [WM !x])(cro«x£: {BP})(r«ourc«: R)» 
(WM = [request: RQ reply-to: CC]) > 
<nrrt-ro»td: 
(G iVn (ONE-AT-A-TJME (queue: [U))(crouid: {NBP*})(r«woarc«: R)» 
(NBP is-a (BUCK-PASSER (continuation: CC)U«rialixen C)))) > 
<rnu«»d-«««.nt«: { |[C <== [rep/y: Afl , |[R <« [rapto*!: RQ reply-to: HBP]J } »> 
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